Re: associate_list( Was: [boost] [BGL] MutablePropertyGraphquestions)
Yes, Emily Winch was working on this, and I thought she was going to submit to boost. The following URL has a paper she wrote about this. http://www.oonumerics.org/tmpw01/schedule.html I can't access that file. Is there a server problem or has it moved? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr - Exception safety reprise
David B. Held [EMAIL PROTECTED] wrote in message b1l1s5$7fm$[EMAIL PROTECTED]">news:b1l1s5$7fm$[EMAIL PROTECTED]... [...] I mean, the optimally_inherit eliminates the empty bases, and yet there is size bloat. So VC++ makes the class bigger for some other reason than that it has empty bases. I will try to write some tests to see why that is, or at least how. Well, I started from an earlier version, and slowly made changes so that it uses the latest RAII version (not with the intermediate ptr_manager yet). On this W2K build, it still gives sizeof(smart_ptr) == 8, so I'm at a loss to explain what causes the inflation on my other machine. I will have to take a hard look at what's different between versions. Could the size possibly change based on different instantiations? Or instantiating certain member functions? Is it conceivable that it would have different behaviour on different Win32 platforms? Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tests on Cray
On Sunday, February 2, 2003, at 05:36 PM, Beman Dawes wrote: At 05:37 PM 2/1/2003, Matthias Troyer wrote: On Saturday, February 1, 2003, at 10:49 PM, Beman Dawes wrote: At 12:39 PM 2/1/2003, Matthias Troyer wrote: cat regress.log | $process_jam_log --- cat regress.log | $process_jam_log $boost_root ... Finally, I wonder why I need the sixth change. How does this work on other platforms? Is there an easier fix? I can answer that one. If process_jam_log is given no argument, it assumes it is being run from some directory within the boost directory tree, and starts recursing upward looking for boost-root. (It assumes any directory with a sub-directory named libs is the boost-root.) That mechanism is probably at play in the script. Specifying a directory argument is particularly useful if ALL_LOCATE_TARGET is being used to place the test targets someplace outside of the boost-root tree, which is a good idea. Since I run it from within the boost directory tree, it probably fails to find it automatically on the Cray. Is that a bug I should investigate further? Maybe. First tell me what the output is from the messages that process_jam_log outputs soon after it starts. The lines that create the messages begin about line 366 in the source file: std::cout boost_root: boost_root.string() '\n' locate_root: locate_root.string() '\n'; I get the following message: prompt$ ../tools/regression/build/bin/process_jam_log/cray/release/ process_jam_log Usage: bjam [bjam-args] | process_jam_log [locate-root] locate-root is the same as the bjam ALL_LOCATE_TARGET parameter, if any. Default is boost-root. boost_root: /u/ph/troyer/boost locate_root: /u/ph/troyer/boost I thus added $boost_root to the command. Was that unnecessary, since as the output shows it seems to find boost_root? In that case I am confused why it prints a usage message. Matthias ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr - Exception safety reprise
David B. Held [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] The problem arises if the user passes an empty policy class with non-trivial ctor or dtor: then the fact that it's being constructed/destructed at different times from the rest of the bases will have visible effects. Ok, now I see the problem, and one conceivable scenario for this is an intrusive ownership policy. It would most likely be empty, yet the cleanup would occur in the d'tor under my latest model, so that it has proper exception safety. Ouch. On the other hand, I just saw a reference to Josuttis Vandevoorde that I recalled reading whereby they refer to a BaseAndMember idiom in which they aggregate the non-empty parameter and derive from the emtpy one, relying on EBO to give optimal size. That's called boost::compressed_pair. Once again, I might be able to reverse the logic and aggregate the empty member and derive from the non- empty one. I guess that depends on how well VC++ friends perform empty member optimization. There is no such thing as empty member optimization. That's true, but we're no longer talking about EBO failure. Even after the empty bases have been eliminated, we still get bloating. So it's just random size adjustment. But you're right that some testing might increase the confidence that the size won't go up. I bet you it's not random, but associated with MI. [...] It would be nice to have some assurance that this won't happen, but the current state of affairs with the MI setup doesn't exactly involve EBO I don't know what you mean by that. I mean, the optimally_inherit eliminates the empty bases, and yet there is size bloat. So VC++ makes the class bigger for some other reason than that it has empty bases. I will try to write some tests to see why that is, or at least how. I repeat, I bet it's MI-related. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: associate_list( Was: [BGL] MutablePropertyGraphquestions)
Jan Langer wrote: Personally, I did not really notice your announcements. Some time ago I wanted a dynamic type-indexed container, in which you specify the required type, and it's either returned, or created. After quite look on some email of yours I decided it's something different and stopped reading. i needed that (or maybe something similar) for the filesystem attributes in the sandbox. i tried to make it compatible to the property map concept. the output can be used as follows (taken from boost-sandbox/libs/filesystem/test/type_pm_test.cpp) AFAIKT, this is quite close to what I wanted/had. And this is indeed different from associative_list-based solution, although subtly. Here, you can store arbitrary number of types and those types are looked up at runtime. With associative_list you'd store a number of pointers of predefined types and lookup is done at compile time. Which one is best, depends on the problem domain. For example, you could allow user to define custom filesystem attributes, provided that classes for that attributes can be constructed from boost::path. (I see that now attributes are constructed with cache as parameter, but that allows for user-defined attributes as well). Consequently, you need dynamic behaviour. Looks like BGL does not need it, and can use associative_list. boost::filesystem::detail:: type_property_map char pm; put int (pm, 'i'); Well, this looks pretty confusing, I'd even say dangerous. If the property map holds chars, then putting int there is questionable. it is implemented using Lokis TypeInfo and a std::map TypeInfo, T where T is the type to store. it is possible to add another layer which sets T to boost::any and converts everything in overloaded get/put functions. the current attribute cache is (nearly) an example for that. Yea, that's very reasonable. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [BGL] MutablePropertyGraph questions
Indeed. boost::any does look very similar. Some differences: - Invoking CMoniker's operator= or copy constructor doesn't duplicate the shrouded object, it duplicates a void * and increments a refcount on the contained CMonikerBase object the idea being that CMoniker's typically contain heavy objects that are costly to copy. You can additionally construct a CMoniker using another version of its constructor I didn't discuss that does not do reference counting on the contained object (freeing the object is somebody else's responsibility). - CMoniker has two methods I didn't discuss: duplicate and clone. Duplicate returns a new CMoniker containing a new CMonikerBase-derived object initialized using its default constructor. Clone returns a new CMoniker containing a new CMonikerBase-derived object initialized using its copy constructor. I'm beginning to understand Emily's suggestion better now I think. One of the things I use the CMoniker::Clone method for is for building factory maps. e.g. typedef std::mapstd::string, CMoniker mapNameIndexedFactory_t; typedef mapNameIndexedFactory_t::iterator mapiterNameIndexedFactory_t; typedef std::maptypeid, CMoniker mapTypeIndexedFactory_t; ... the idea being that I might use this for: mapNameIndexedFactory_t mapNameIndexedFactory; // ... populate map mapiterNameIndexedFactory_t mapiterNameIndexedFactory = mapNameIndexFactory.find(some name); CMoniker newDuplicateMoniker = (*mapiterNameIndexedFactory).second.Duplicate(); CMoniker newClonedMoniker = (*mapiterNameIndexedFactory).second.Clone(); ... so I'm still trying to figure out if Emily Winch's varlist helps me do this more elegantly that my admittedly inelegant CMoniker thing. - Regards cdr Vladimir Prus [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Chris Russell wrote: Let me first describe my heterogeneous container hack and perhaps you could point why it's poor (your feel better on a quick read of your paper and this is a good way to help us all understand this a bit better). My goal was to be able to use standard STL containers and iterators with heterogeneous collections of objects. My hack was to declare a class CMoniker that takes a pointer to some CMonikerBase-derived class through a templated constructor. This constructor does two things: it casts the pointer to a void * and stores it in a private member. Additionally it uses RTTI to record the type. CMonikerBase is invasive; it provides reference counting for the object and operator overloads for STL containers. Any class that derives from CMonikerBase can then be stuffed into a CMoniker, and I then use the standard STL containers/iterators to work with homogenous collections. A CMoniker has a templated operator: template typename Type operator Type() that internally uses RTTI to test Type and throw an exception if it doesn't match the internal type squirreled away in the constructor. Ugly - yes. The filtering operation you propose in your paper is similar to little helper classes I write to enumerate elements in my some_stl_containerCMoniker to produce another container full of objects of a given type - again this is inelegant but it does seem to work. I'm probably wrong, but it looks like boost::any. I can't tell a difference, at least. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: ublas::type_traitsdouble::abs doesn't work with VC .NET
Hi Joerg, At 09:27 03.02.2003, you wrote: Hi Julius, it looks as if your mail didn't find it's way to the boost ml. You wrote: Sorry, I had a typo in the boost ml address. You included my message in your reply, so I don't send it again. (snipped) IIRC the signatures 'float abs(float)' and 'double abs(double)' should be part of cmath, which is included in ublas/traits.hpp. I think they should, too, but they aren't. I don't know why, but the Standard (Table 81, Section, 26.5, p596) puts abs, div, rand and srand into cstdlib and all the others like sqrt and asin into cmath. The reason why ublas/type_traits.hpp still compiles is that Microsoft says using ::abs in cmath, although the Standard doesn't put it there. By the way: VC 6 does have cmath and cstdlib headers, too. These headers just import math.h and stdlib.h within namespace std brackets. This apparently wasn't enough to convince boost to omit the BOOST_NO_STDC_NAMESPACE #define for VC 6. It seems that probably for legacy reasons most cmath headers declare abs, at least as int abs(int), although it's seems to be against the Standard. Otherwise you would have had many compiler errors already: ublas::type_traits is fully specialized so they are always compiled. Still, I think you maybe should #include cstdlib in ublas/type_traits to be ready for a really conforming library implementation. Julius Julius Muschaweck _ OEC AG Paul-Gerhardt-Allee 42 81245 Muenchen, Germany Phone: +49 89 820050-30 Fax: +49 89 820050-41 e-mail: [EMAIL PROTECTED] Internet: www.oec.net __
[boost] Test Tool Proposal (test_tools.hpp)
I suggest adding the following (or a similar) macro to test_tools.hpp:
#define BOOST_CHECK_EQUAL_MESSAGE(left_, right_, message_) \
boost::test_toolbox::detail::equal_and_continue_impl((left_),
(right_), \
boost::test_toolbox::detail::wrapstrstream() #left_ ==
#right_ ( message_ ) , __FILE__, __LINE__)
Sometimes in a unit test one has got a function/method to check certain
properties of an object in order to avoid duplicating lots of code
--- SNIP Example ---
MyObject* my1 = new MyObject(1, 2, 3);
BOOST_CHECK_EQUAL(my1-getA(), 1);
BOOST_CHECK_EQUAL(my1-getB(), 2);
BOOST_CHECK_EQUAL(my1-getC(), 3);
MyObject* my2 = new MyObject(4, 5, 6);
BOOST_CHECK_EQUAL(my2-getA(), 4);
BOOST_CHECK_EQUAL(my2-getB(), 5);
BOOST_CHECK_EQUAL(my2-getC(), 6);
--- SNIP ---
can be refactored into:
--- SNIP Example refactored ---
void checkMyObject(MyObject* my, int a, int b, int c)
{
BOOST_CHECK_EQUAL(my-getA(), a);
BOOST_CHECK_EQUAL(my-getB(), b);
BOOST_CHECK_EQUAL(my-getC(), c);
}
MyObject* my1 = new MyObject(1, 2, 3);
checkMyObject(my1, 1, 2, 3);
MyObject* my2 = new MyObject(4, 5, 6);
checkMyObject(my2, 4, 5, 6);
--- SNIP ---
The problem with the second version is that if the check for equality
fails, the only output is the line number within checkMyObject() that
failed. No hint about the calling line is present. Ideally all macros
should print out a stack trace (as done in e.g. Java), but from my limited
knowledge of C++ I guess that this is not (easily) possible, so
introducing a BOOST_CHECK_EQUAL_MESSAGE macro is the second best solution
IMHO:
--- SNIP Example with new macro ---
void checkMyObject(MyObject* my, int context, int a, int b, int c)
{
BOOST_CHECK_EQUAL_MESSAGE(my-getA(), a, context);
BOOST_CHECK_EQUAL_MESSAGE(my-getB(), b, context);
BOOST_CHECK_EQUAL_MESSAGE(my-getC(), c, context);
}
MyObject* my1 = new MyObject(1, 2, 3);
checkMyObject(my1, __LINE__, 1, 2, 3);
MyObject* my2 = new MyObject(4, 5, 6);
checkMyObject(my2, __LINE__, 4, 5, 6);
--- SNIP ---
Note that instead of using an int context we could also have a std::string
or any other streamable object. Using an int and the __LINE__ macro is
just convenient here.
Best regards,
Robert
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: ublas::type_traitsdouble::abs doesn't work with VC.NET
Hi Julius, you wrote: [snip] IIRC the signatures 'float abs(float)' and 'double abs(double)' should be part of cmath, which is included in ublas/traits.hpp. I think they should, too, but they aren't. I don't know why, but the Standard (Table 81, Section, 26.5, p596) puts abs, div, rand and srand into cstdlib and all the others like sqrt and asin into cmath. The reason why ublas/type_traits.hpp still compiles is that Microsoft says using ::abs in cmath, although the Standard doesn't put it there. OK, this raises the question, if 26.5.5 and 26.5.6 must be read together or if the overloads of 26.5.6 should be splitted into cstdlib and cmath according to table 80/81. By the way: VC 6 does have cmath and cstdlib headers, too. These headers just import math.h and stdlib.h within namespace std brackets. This apparently wasn't enough to convince boost to omit the BOOST_NO_STDC_NAMESPACE #define for VC 6. It seems that probably for legacy reasons most cmath headers declare abs, at least as int abs(int), although it's seems to be against the Standard. Otherwise you would have had many compiler errors already: ublas::type_traits is fully specialized so they are always compiled. Still, I think you maybe should #include cstdlib in ublas/type_traits to be ready for a really conforming library implementation. OK, I'll add #include cstdlib to ublas/traits.hpp. Does this solve the original problem with .NET? Thanks, Joerg ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: borland patch for random/graph tests
Beman Dawes wrote: * Patches really are best to be supplied as diff output; that cuts errors applying them. The -c switch helps make them more readable. It may be better to attach the diff output as a file, if long lines would be wrapped by pasting it inline. Is this form better? [diff through WinCVS] cvs diff uniform_smallint.hpp (in directory C:\Projects\3rdParty\boost\boost\random\) Index: uniform_smallint.hpp === RCS file: /cvsroot/boost/boost/boost/random/uniform_smallint.hpp,v retrieving revision 1.20 diff -r1.20 uniform_smallint.hpp 190a191,192 #elif defined( __BORLANDC__ ) typedef typename detail::uniform_smallint boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false ::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; *CVS exited normally with code 1* cvs diff uniform_int.hpp (in directory C:\Projects\3rdParty\boost\boost\random\) Index: uniform_int.hpp === RCS file: /cvsroot/boost/boost/boost/random/uniform_int.hpp,v retrieving revision 1.21 diff -r1.21 uniform_int.hpp 208a209,210 #elif defined( __BORLANDC__ ) typedef typename detail::uniform_int boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false ::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; *CVS exited normally with code 1* * Testing for defined( __BORLANDC__ ) is usually discouraged because it will fail when the compiler changes to a new version which behaves differently. Also, there may be a Boost config macro which applies, and is the preferred way to detect a compiler deficiency. Yes, and I probably should have used the new BOOST_WORKAROUND macros too. In this case the same borland bug is responsible for both patches, suggesting that if there is not yet a BOOST_specific macro to test it might be useful to add one. Of course, there may already be one that is appropriate known to those more familiar with the workarounds. The issue is with (at least) Borland's treatment of BOOST_STATIC_CONSTANT. For some reason it refuses to allow use of const static bool members without a class instance. In this case all that was needed was a compile-time boolean flag to pick the right specialization so the test could be performed directly in-place. -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::format problems
Le jeu 16/01/2003 à 15:13, Yitzhak Sapir a écrit : I tried to use boost::format in a simple manner. The line in question is: std::cout boost::format(%0d) % some_function(); Unfortunately, in order for this to compile I have to: 1) #include locale 2) add a line using namespace std; before I include boost/format.hpp what compiler (and standard lib if not the default one) are you using ? -- Samuel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
From: Gennaro Prota [EMAIL PROTECTED]
On Sat, 1 Feb 2003 20:01:15 -0800, Eric Niebler [EMAIL PROTECTED]
wrote:
Gennaro Prota [EMAIL PROTECTED] wrote
Well, then I imagine you would prefer the old semantics. Was there
anybody complaining that being not enough?
Yes, I was. A while back, I pointed out to Rani that is_base_and_derived
was insufficient to implement is_com_ptr, a trait I needed. In COM
programming, every interface inherits from IUnknown, and many COM objects
implement multiple interfaces. So is_base_and_derivedIUnknown,
MyCOMObject was almost always ambiguous.
I was content to gripe, but Rani actually did something about it. The
new
behavior of is_base_and_derived is very welcome, IMO.
Yes, Rani pointed out the usage for COM interfaces too, and that's a
good one. I'm only a little perplexed about inaccessible bases,
because the relevant example looks a little artificial; that doesn't
mean that there aren't better examples, or that it is a good example
but I have not understood it. As I said in another post, let's see how
will this behave in practice. After all, boost is (also) a sort of
test-bed for C++ libraries.
I think I have a use case for the new behavior.
When is_base_and_derivedB, D says true, this means that every object of
type D has a subobject of type B. This can be used to determine the order of
if statements in the code below:
if(dynamic_castD*(p))
{
// ...
}
else if(dynamic_castB*(p))
{
// ...
}
Modern C++ Design has an example of that.
The corrolaries are:
1. is_base_and_derivedX, X must be false, or the predicate won't be
antireflexive and mpl::sort won't work.
2. mpl::sort must work with a partial ordering predicate.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] MutablePropertyGraph questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Emily, Emily Winch wrote: | On Wed, 2003-01-29 at 15:30, Jeremy Siek wrote: | I would be very happy to submit it to boost, and several people have | suggested this. I think it would be a mistake to submit it for a formal | review without any prior discussion. Yep. What about making it available in the sandbox and improving the compiler support. | | I have mentioned this a couple of times now, and the lack of feedback | led me to think that nobody was particularly interested in it. That's | easy to believe, since when I wrote the paper it was really more from a | hey, this is cool perspective than hey, this would be really useful. It is definitely cool. If it is useful I don't know. | | So, I have a question: Why no feedback? | | a) The library is not something that people think makes sense in Boost. No | b) The library uses the wrong approach to the problem and someone should | submit something else. Haven't heard of anything so far. | c) The library is not something that anyone would really use. (Hey, | Jeremy. I'm sure you said you would use it). As said before I am not sure that it is useful. To me the concept is really usefull but there are practical issues that may outweigh the benefit. One problem is the organization of names, mostly key type names and where to put them. Another problem I encountered is that using alists does not neccessarily reduce the amount of source code that is written for the problem I tried to adress. This is partly due to syntactical issues. | d) People think it's a great idea but just never got round to having a | look or making any comments. One problem may be that the code does not compile on a wide range of compilers. It is a lot easier to play with something that compiles out of the box, than wading through endless strings of template related error messages. Don't get me wrong, I am not complaining about the code it is just a real life problem. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+PmDF0ds/gS3XsBoRAo/WAJ99uvlUbQt8ksYuZZ3tJW0I8GJx8QCbBu1+ WqRWy183/8UgpdpKIYwC8ZI= =ao1M -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A functional bind-ing exercice...
Somewhere in the E.U., le 03/02/2003 Bonjour In article 001b01c2c942$cd3f08c0$1d00a8c0@pdimov2, Peter Dimov [EMAIL PROTECTED] wrote: From: Hubert Holin [EMAIL PROTECTED] Somewhere in the E.U., le 31/01/2003 In article 00d801c2c927$8d06dd20$1d00a8c0@pdimov2, Peter Dimov [EMAIL PROTECTED] wrote: From: Hubert Holin [EMAIL PROTECTED] eater(::boost::bind(std::mem_fun_ref((A::operator ())), a)); eater(a) is much simpler, I think. Indeed! eater(::boost::bind(std::mem_fun_ref((AN::operator ())), an, 1)); eater(bind(an, 1)); Doesn't work (with MWCWPro 8.3, at least), giving me the error: Error : 'result_type' is not a member of class 'AN' My mistake. bind needs a result_type typedef in AN to determine the return type of its operator(). The alternative is to supply it explicitly: bindvoid(an, 1)). All is fine now. Hopefully this exercice will be helpful to others (it certainely was for me!). Merci HH ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Array support [was SmartPtr (Loki) - auto_ptr/movec'torissue]
On Sunday, February 2, 2003, at 11:40 PM, Andrei Alexandrescu wrote: By and large, I believe smart pointers to arrays are an oxymoron and should not be supported. Why? -Howard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MSVC .NET + BOOST_NO_STDC_NAMESPACE (formerublas::type_traitsdouble::abs doesn't work with VC .NET)
Hi Kresimir, hi Joerg,
At 11:41 03.02.2003, you wrote:
Hi Joerg, hi Julius,
I am not sure whether the message
http://groups.google.com/groups?selm=3E23CE08.893428D0%40bdal.de
from comp.lang.c++.moderated is on topic ;o),
but maybe it is worth a look.
Thanks. The message is exactly on topic. The author presents a nice
program that determines the availability of abs overloads, and a reply to
this message explains that
In
math.h, the section about abs() and fabs() overloads is #ifdefed by
_MSC_EXTENSIONS. That is, they
exist ONLY
in strict mode. If you disable language extensions, your code shows
that
the MS
VC++ 7 is standard compliant in the sense of abs/fabs signatures.
I checked that with .NET, and he is right. With /Za (disable
language extensions), double abs(double) and the whole load of float
sin(float) etc. is indeed declared and ublas::type_traitsdouble
works also with .NET.
But .NET with /Za is not exactly what I think most people want. For
example, you can't even define private member functions with private
return values outside of the class definition. Look at the following
lines which are copied and pasted from the Standard, clause 11:
class
A {
typedef
int I; // private member
I
f();
friend
I g(I);
static
I x;
};
A::I
A::f() { return 0; }
A::I
g(A::I p = A::x);
A::I
g(A::I p) { return 0; }
A::I A::x
= 0;
Here, all
the uses of A::I are well-formed because A::f and A::x are members of
class A and g is a
friend of
class A. This implies, for example, that access checking on the first use
of A::I must be deferred
until it
is determined that this use of A::I is as the return type of a member of
class A.
VC. NET with /Za complains that I cannot use A::I etc because it's
private.
Back to the
BOOST_NO_STDC_NAMESPACE
issue:
Only if /Za is set and thus _MSC_EXTENSIONS is undefined, then VC .NET
seems to have all declarations for the math function overloads
properly.
Maybe you could make the #define of BOOST_NO_STDC_NAMESPACE
for VC .NET depend on the
_MSC_EXTENSIONS switch: If
_MSC_EXTENSIONS is defined, the math function overloads are missing and
BOOST_NO_STDC_NAMESPACE
should be defined.
Julius
Julius Muschaweck
_
OEC AG
Paul-Gerhardt-Allee 42
81245 Muenchen, Germany
Phone: +49 89 820050-30
Fax: +49 89 820050-41
e-mail: [EMAIL PROTECTED]
Internet:
www.oec.net
__
[boost] Re: Thread library with BOOST_HAS_PTHREAD
Shimshon Duvdevan wrote: [...] So, if upgrading Solaris is not an option, I should patch boost.threads each time a new version is out? Isn't it easier to add a couple of #ifdefs? :) I'd suggest that you should just wait for a new version that would hopefully allow you to have something along the lines of: . . . #ifdef BROKEN_SOLARIS thread::attr() .set_scope( PTHREAD_SCOPE_SYSTEM ) . // see below #endif new_thread( routine /*, arg(s)...*/ ) . . . ;-) regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Smart pointers: One more implementation + question
I would like to offer for discussion one more implementation of
reference counting smart pointer. It has taken much of the design
from boost::shared_ptr/weak_ptr and is quite similar to it, but
supports different types of reference counting (intrusive, semi-
intrusive, non-intrusive + weak references, dummy reference
counting) within a single smart pointer class. The library is also
more performance-oriented and has extra tools implemented.
Please find more info in the Readme at
http://groups.yahoo.com/group/boost/files/refc/Readme.html
I am not sure that there is a place for another one smart pointer
library in Boost. That is why I have not made complete
boostification. Nevertheless I would be grateful for any comment
that will help it to mature.
Files:
Readme:
http://groups.yahoo.com/group/boost/files/refc/Readme.html
QA:
http://groups.yahoo.com/group/boost/files/refc/Refc_library_QA.html
Complete package:
http://groups.yahoo.com/group/boost/files/refc/refc_ptr.zip
(About 63K. Includes examples and preliminary documentation)
Also there is a question related to boost::shared_ptr: what the
drawbacks would be in implementing it via void*? I mean
templateclass T class shared_ptr
{
void * px;
detail::shared_count pn;
...
public:
T * get() const
{
return static_castT*(px);
}
}
The advantage is that with void*-based implementation all
shared_ptrs are layout-compatible and thus std containers may
be specialized for shared_ptr to reduce code bloat (since not all
linkers are as smart as MSVC++).
Probably this was already discussed and declined. Currently I see
the two issues: slight performance degradation on some platforms
(which platforms?) and prohibition of the get() method for
incomplete types. What else?
Pavel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Smart pointers: One more implementation + question
From: Pavel Vasiliev [EMAIL PROTECTED]
[...]
Also there is a question related to boost::shared_ptr: what the
drawbacks would be in implementing it via void*? I mean
templateclass T class shared_ptr
{
void * px;
detail::shared_count pn;
...
public:
T * get() const
{
return static_castT*(px);
}
}
The advantage is that with void*-based implementation all
shared_ptrs are layout-compatible and thus std containers may
be specialized for shared_ptr to reduce code bloat (since not all
linkers are as smart as MSVC++).
There are no significant drawbacks that I can see.
The only drawback is that with a void * px it's easier to create a broken
implementation that will almost work. For example
templateclass Y shared_ptrT::shared_ptr(shared_ptrY const rhs):
px(rhs.px), pn(rhs.pn) {}
is buggy, and should now be
templateclass Y shared_ptrT::shared_ptr(shared_ptrY const rhs):
px(static_castT*(rhs.get())), pn(rhs.pn) {}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re[2]: [boost] Smart pointers: One more implementation + question
The advantage is that with void*-based implementation...
There are no significant drawbacks that I can see.
The only drawback is that with a void * px it's easier to create a broken
implementation that will almost work. For example
templateclass Y shared_ptrT::shared_ptr(shared_ptrY const rhs):
px(rhs.px), pn(rhs.pn) {}
is buggy, and should now be
templateclass Y shared_ptrT::shared_ptr(shared_ptrY const rhs):
px(static_castT*(rhs.get())), pn(rhs.pn) {}
Yes, this needs much care. One must use something like:
// Will not compile if there is no implicit conversion from U* to T*.
template typename T, typename U
inline
T* implc(U *pU) // nothrow
{
return pU;
}
(this is taken from the implementation of refc_ptr)
and then
templateclass Y shared_ptrT::shared_ptr(shared_ptrY const rhs):
px(implcT(rhs.get())), pn(rhs.pn) {}
Since the smart pointers are especially useful when stored in std
containers instead of raw pointers, may be it worth troubles to
specialize containers for their void*-based versions? Both
boost::shared_ptr and my (newly proposed) refc_ptr potentially allow
this.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: auto_ptr/move issue
Peter Dimov [EMAIL PROTECTED] wrote in message
001b01c2cb95$de5e8fe0$1d00a8c0@pdimov2">news:001b01c2cb95$de5e8fe0$1d00a8c0@pdimov2...
[...]
And finally Mojo approximates:
public:
mojoized(mojoized const rhs); // can copy
mojoized(mojoized rhs); // but can also move for efficiency reasons
Really? http://www.cuj.com/experts/2102/alexandr.htm?topic=experts
has:
class mojo_ptr : public mojo::enablemojo_ptr
{
// *** Here ***
mojo_ptr(const mojo_ptr); // const sources are NOT accepted
public:
// source is a temporary
mojo_ptr(mojo::temporarymojo_ptr src)
{
mojo_ptr rhs = src.get();
... use rhs to perform a destructive copy ...
}
// source is a function's result
mojo_ptr(mojo::fnresultmojo_ptr src)
{
mojo_ptr rhs = src.get();
... use rhs to perform a destructive copy ...
}
...
};
That looks like Howard's protocol to me, unless I'm missing
something. I understand Howard's point now, which is the
important thing.
In fact, my understanding is that Howard's move_ptr *is* more
similar to mojo_ptr than auto_ptr, because auto_ptr has
auto_ptr(auto_ptr), which is exactly the thing Howard is
crusading against.
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost::format problems
I use MSVC6.5 and STLPort. Well, now it seems to work, except: 1) I don't have wformat defined, and I need to define it myself. I can see the bunch of defines that go into deciding this in the config, and I'm not sure why in the end boost::format concludes that because there's a using ::x compiler bug (BOOST_NO_USING_TEMPLATE), that means I can't have boost::wformat. 2) When I define wformat as: typedef boost::basic_formatwchar_t wformat; I get: c:\boost\boost_cvs\boost\format\format_fwd.hpp(29) : error C2065: 'charT' : undeclared identifier on this line: templateclass charT, class Traits = BOOST_IO_STD char_traitscharT class basic_format; But these are minor. I'm not sure why it didn't work before. -Original Message- From: Samuel Krempp [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 2:30 PM To: Boost mailing list Subject: Re: [boost] boost::format problems Le jeu 16/01/2003 à 15:13, Yitzhak Sapir a écrit : I tried to use boost::format in a simple manner. The line in question is: std::cout boost::format(%0d) % some_function(); Unfortunately, in order for this to compile I have to: 1) #include locale 2) add a line using namespace std; before I include boost/format.hpp what compiler (and standard lib if not the default one) are you using ? -- Samuel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] io operations for stl containers?
Hi, after having to output std::vector to stream again and again using custom solution, I started to wonder why we don't have a solution in boost. Does it makes sense to include operators for vectors, sets, etc? I was thinking about boost/io/vector.hpp boost/io/set.hpp and so on. There are basically two approaches: 1. Operators use fixed format: bracked list with commas between values for vector, for example. 2. Manipulators are provided to set brackets and separators. I had implemented the second approach some time ago, but it turned out that was overkill. So, 1) looks better now. Thoughts? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [BGL] MutablePropertyGraph questions
On Sun, 2003-02-02 at 22:37, Chris Russell wrote: Hi Emily, I just read your paper and think it's excellent. A while ago (some months past), I think I hacked together a solution to a similar problem and made a mental note to post it into the Wiki for analysis by folks who really know what they're doing at some point in the future. You post (sorry I was not previously following this thread) brings this back to my attention. I'm not sure I completely understand your approach (my ignorance). Would you please clarify these points for me: Your heterogeneous list mechanism employs custom containers that look like STL containers? Or can you actually use STL containers? Algorithms must be written custom and your paper explains how. Is this correct? Or am I missing something? Yes. I wrote an associative_list class that looks like a heterogenous STL multimap. It's type-safe in that trying to retrieve the wrong type results in a compile-time error. Yes, custom algorithms are required, and the paper explains how. The intent is for several algorithms to be provided with the associative_list, and these algorithms would also work on a hypothetical tuple_iterator, or on iterators into any similar container, for example, a heterogenous set. Let me first describe my heterogeneous container hack and perhaps you could point why it's poor (your feel better on a quick read of your paper and this is a good way to help us all understand this a bit better). My goal was to be able to use standard STL containers and iterators with heterogeneous collections of objects. My hack was to declare a class CMoniker that takes a pointer to some CMonikerBase-derived class through a templated constructor. This constructor does two things: it casts the pointer to a void * and stores it in a private member. Additionally it uses RTTI to record the type. CMonikerBase is invasive; it provides reference counting for the object and operator overloads for STL containers. Any class that derives from CMonikerBase can then be stuffed into a CMoniker, and I then use the standard STL containers/iterators to work with homogenous collections. A CMoniker has a templated operator: template typename Type operator Type() that internally uses RTTI to test Type and throw an exception if it doesn't match the internal type squirreled away in the constructor. Ugly - yes. The filtering operation you propose in your paper is similar to little helper classes I write to enumerate elements in my some_stl_containerCMoniker to produce another container full of objects of a given type - again this is inelegant but it does seem to work. As someone already pointed out, this is quite similar to Boost.Any. My approach is fairly different in that the list of types is fixed at compile-time, like a typelist. I should point out that the typelist-equivalent of your container would be Boost.Tuple, which is not an associative container like mine. What I use this for (question: can I use your approach to achieve these ends better?): If you know the set of types at compile time, the typelist approach is a) more efficient and b) typesafe. If you don't, this approach simply doesn't work. In your paper section 7: Where varlist can be useful you discuss using your technique to work with heterogeneous collections of classes containing different settings. I use my CMoniker hack similarly. I pass around references to my some_stl_containerCMoniker and let the called method determine which elements in the container they know how to deal with - effectively I enumerate the CMoniker's and dispatch on type. Similar to mine, except one would always know the type at compile-time, so no runtime dispatch would be required. You fish the object out of the container and it already is the correct type. Another place where I use CMoniker (and this is directly related to the mutable property graph I think), is in BGL property maps. This effectively lets me associate any CMonikerBase-derived class with an edge or vertex using an unmodified version of Mr. Siek's property map. What's it good for? File this under this is cool: I use BGL directed graphs, specifically forests, to abstract expressions. Vertices are operands, edges are operators. I use a topological sort and a variant of Alexandrescu's double dispatch idea to evaluate the entire graph as an expression generically. Specifically I use this approach to deserialize XML streams but I think it's generally useful. This is something that my class is not any use for: your expressions, I assume, are built up at runtime. In fact, my class _is_ a BGL property map (I mean that it does the same thing, not that it necessarily conforms to the required interface), and you are deliberately subverting the compile-time type checking of the property map to achieve your run-time dispatch. So do you think I can use your varlist idea instead of my CMoniker? That would be excellent as I don't really like
Re: associate_list( Was: [boost] [BGL] MutablePropertyGraphquestions)
On Mon, 2003-02-03 at 08:02, Matthias Troyer wrote: Yes, Emily Winch was working on this, and I thought she was going to submit to boost. The following URL has a paper she wrote about this. http://www.oonumerics.org/tmpw01/schedule.html I can't access that file. Is there a server problem or has it moved? Works for me. Try the paper itself? http://www.oonumerics.org/tmpw01/winch.pdf Emily ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tests on Cray
At 03:10 AM 2/3/2003, Matthias Troyer wrote: Maybe. First tell me what the output is from the messages that process_jam_log outputs soon after it starts. The lines that create the messages begin about line 366 in the source file: std::cout boost_root: boost_root.string() '\n' locate_root: locate_root.string() '\n'; I get the following message: prompt$ ../tools/regression/build/bin/process_jam_log/cray/release/ process_jam_log Usage: bjam [bjam-args] | process_jam_log [locate-root] locate-root is the same as the bjam ALL_LOCATE_TARGET parameter, if any. Default is boost-root. boost_root: /u/ph/troyer/boost locate_root: /u/ph/troyer/boost I thus added $boost_root to the command. Was that unnecessary, since as the output shows it seems to find boost_root? Yes, it was unnecessary. It looks like process_jam_log is working correctly. In that case I am confused why it prints a usage message. Just a local convention of mine to always print a usage message if a program is invoked without arguments. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: associate_list( Was: [BGL] MutablePropertyGraphquestions)
Vladimir Prus wrote:
i needed that (or maybe something similar) for the filesystem
attributes in the sandbox. i tried to make it compatible to the
property map concept. the output can be used as follows (taken from
boost-sandbox/libs/filesystem/test/type_pm_test.cpp)
AFAIKT, this is quite close to what I wanted/had. And this is indeed
different
from associative_list-based solution, although subtly. Here, you can store
arbitrary number of types and those types are looked up at runtime. With
associative_list you'd store a number of pointers of predefined types
and lookup is done at compile time.
no, you can store an arbitrary number of objects of the same type. and
they are just looked up with the type. that means to implement what you
want there should be a type_property_map boost::any where the get/put
functions convert from any to the looked up type. i took the cache class
as it is in the sandbox and modified it. now it should meet your needs
(it still needs the original type_property_map):
class type_pm
{
public:
typedef read_write_property_map_tag category;
// access on a certain value
// at is used because operator[] is not
// possible without an object as key
template typename T
T at ()
{
any a = map_.template at T ();
// no object of this type exists yet
// - construct one
if (a.empty ())
a = T (*this);
// conversion to required type
T *v = any_cast T (a);
assert (v);
return *v;
}
private:
typedef detail::type_property_map any map_type;
map_type map_;
};
template typename T
T get (type_pm pmap)
{
return pmap.template at T ();
}
template typename T
void put (cache pmap, T v)
{
pmap.template at T () = v;
}
usage:
type_pm a;
put int (a, 7);
put char (a, 'i');
put char (a, 'b');
assert (get int (a) == 7);
assert (get char (a) == 'b');
assert (a.template at int () == 7);
the a.template at () is really ugly but i found no better solution.
Which one is best, depends on the problem domain. For example, you could
allow
user to define custom filesystem attributes, provided that classes for
that attributes can be constructed from boost::path. (I see that now
attributes are constructed with cache as parameter, but that allows for
user-defined attributes as well). Consequently, you need dynamic
behaviour. Looks like BGL
does not need it, and can use associative_list.
boost::filesystem::detail::
type_property_map char pm;
put int (pm, 'i');
Well, this looks pretty confusing, I'd even say dangerous. If the
property map
holds chars, then putting int there is questionable.
no, the type stored in the map is char. and int is the lookup key. i
dont know if bgl needs it. i just thougth that it migth be something
which also could help in another situation than only filesystem.
jan
--
jan langer ... [EMAIL PROTECTED]
pi ist genau drei
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Thread library with BOOST_HAS_PTHREAD
Alexander Terekhov writes: Shimshon Duvdevan wrote: [ ... Solaris - PTHREAD_SCOPE_SYSTEM ... ] Can anyone verify the supposed boost threads library behavior on a multi-processor Solaris machine? Is this behavior the intended one? Perhaps a bug fix is necessary. That's Solaris' bug and actually, they've already kinda-fixed it recently. More info on this can be found in the c.p.t.(*) archive on google. So, if upgrading Solaris is not an option, I should patch boost.threads each time a new version is out? Isn't it easier to add a couple of #ifdefs? :) Supply me with a proper patch, that works both before and after a Solaris upgrade (i.e. let's not have extra code when it's not needed), and I'll apply it to the library. -- William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost/mpl/integral_c.hpp and Borland
- Original Message - From: David Abrahams [EMAIL PROTECTED] To: Beman Dawes [EMAIL PROTECTED] Cc: boost [EMAIL PROTECTED]; Aleksey Gurtovoy [EMAIL PROTECTED]; Fernando Cacciola [EMAIL PROTECTED] Sent: Friday, January 31, 2003 9:58 PM Subject: [boost] Re: boost/mpl/integral_c.hpp and Borland Beman Dawes [EMAIL PROTECTED] writes: Dave, Your change to boost/mpl/integral_c.hpp broke a lot of Borland 5.61 compiles. I thought something like that might happen on the broken compilers. I don't really know what the best approach here might be, other than to take out casts for those compilers. I'm not even sure if integral_csome_enum,... (which is what the change accomodates) is appropriate. Perhaps we should have enum_c with no next,prior for this purpose. I see that integral_c has been fixed now. I'm puzzled though about why the apparently simple fix didn't worked on Borland. On bcc5.5.1, it says: Cannot cast from 'T' to 'T' (!?) Anyway, I'd like to know what is the role of integral_c; in particular, with respect to 'int_c'. IOWs, why does it has next/prior? I know that you could pass an integral_c to a metafunction which would operate on a generic Integral metavalue, doing ::next for instance; but my question is: when and why would you pass 'integral_c' instead of 'int_c'? Fernando Cacciola According to the See the Win32 tests just posted. --Beman -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [BGL] MutablePropertyGraph questions
Thank you for taking the time to dissect my e-mail Emily: ... I assume, your BGL expressions are built up at runtime. True. In fact, my class _is_ a BGL property map (I mean that it does the same thing, not that it necessarily conforms to the required interface), and you are deliberately subverting the compile-time type checking of the property map to achieve your run-time dispatch. Yes I am. For runtime stuff, I'd have a good look at Boost.Any. For compile time stuff, I think the type-checking advantage is a strong argument for going with an associative_list (or in your case, probably a tuple). There are pieces of my overall algorithm where I _do_ know the types a-priori. And clearly my runtime hack isn't the best way to deal with these cases. These are extremely helpful pointers. Thank you - I've got some reading to do. - Regards cdr Emily Winch [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Sun, 2003-02-02 at 22:37, Chris Russell wrote: Hi Emily, I just read your paper and think it's excellent. A while ago (some months past), I think I hacked together a solution to a similar problem and made a mental note to post it into the Wiki for analysis by folks who really know what they're doing at some point in the future. You post (sorry I was not previously following this thread) brings this back to my attention. I'm not sure I completely understand your approach (my ignorance). Would you please clarify these points for me: Your heterogeneous list mechanism employs custom containers that look like STL containers? Or can you actually use STL containers? Algorithms must be written custom and your paper explains how. Is this correct? Or am I missing something? Yes. I wrote an associative_list class that looks like a heterogenous STL multimap. It's type-safe in that trying to retrieve the wrong type results in a compile-time error. Yes, custom algorithms are required, and the paper explains how. The intent is for several algorithms to be provided with the associative_list, and these algorithms would also work on a hypothetical tuple_iterator, or on iterators into any similar container, for example, a heterogenous set. Let me first describe my heterogeneous container hack and perhaps you could point why it's poor (your feel better on a quick read of your paper and this is a good way to help us all understand this a bit better). My goal was to be able to use standard STL containers and iterators with heterogeneous collections of objects. My hack was to declare a class CMoniker that takes a pointer to some CMonikerBase-derived class through a templated constructor. This constructor does two things: it casts the pointer to a void * and stores it in a private member. Additionally it uses RTTI to record the type. CMonikerBase is invasive; it provides reference counting for the object and operator overloads for STL containers. Any class that derives from CMonikerBase can then be stuffed into a CMoniker, and I then use the standard STL containers/iterators to work with homogenous collections. A CMoniker has a templated operator: template typename Type operator Type() that internally uses RTTI to test Type and throw an exception if it doesn't match the internal type squirreled away in the constructor. Ugly - yes. The filtering operation you propose in your paper is similar to little helper classes I write to enumerate elements in my some_stl_containerCMoniker to produce another container full of objects of a given type - again this is inelegant but it does seem to work. As someone already pointed out, this is quite similar to Boost.Any. My approach is fairly different in that the list of types is fixed at compile-time, like a typelist. I should point out that the typelist-equivalent of your container would be Boost.Tuple, which is not an associative container like mine. What I use this for (question: can I use your approach to achieve these ends better?): If you know the set of types at compile time, the typelist approach is a) more efficient and b) typesafe. If you don't, this approach simply doesn't work. In your paper section 7: Where varlist can be useful you discuss using your technique to work with heterogeneous collections of classes containing different settings. I use my CMoniker hack similarly. I pass around references to my some_stl_containerCMoniker and let the called method determine which elements in the container they know how to deal with - effectively I enumerate the CMoniker's and dispatch on type. Similar to mine, except one would always know the type at compile-time, so no runtime dispatch would be required. You fish the object out of the container and it already is the correct type. Another place where I use CMoniker (and this is directly related to the mutable property graph I think), is in BGL property maps. This effectively
Re: associate_list( Was: [boost] [BGL] MutablePropertyGraphquestions)
On Monday, February 3, 2003, at 06:20 PM, Emily Winch wrote: On Mon, 2003-02-03 at 08:02, Matthias Troyer wrote: Yes, Emily Winch was working on this, and I thought she was going to submit to boost. The following URL has a paper she wrote about this. http://www.oonumerics.org/tmpw01/schedule.html I can't access that file. Is there a server problem or has it moved? Works for me. Try the paper itself? http://www.oonumerics.org/tmpw01/winch.pdf Thanks, that works! Matthias ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tests on Cray
On Monday, February 3, 2003, at 04:37 PM, Beman Dawes wrote: At 03:10 AM 2/3/2003, Matthias Troyer wrote: prompt$ ../tools/regression/build/bin/process_jam_log/cray/release/ process_jam_log Usage: bjam [bjam-args] | process_jam_log [locate-root] locate-root is the same as the bjam ALL_LOCATE_TARGET parameter, if any. Default is boost-root. boost_root: /u/ph/troyer/boost locate_root: /u/ph/troyer/boost I thus added $boost_root to the command. Was that unnecessary, since as the output shows it seems to find boost_root? Yes, it was unnecessary. It looks like process_jam_log is working correctly. In that case I am confused why it prints a usage message. Just a local convention of mine to always print a usage message if a program is invoked without arguments. Well, that explains it. Since the output was not correct at first (a jam problem as we realized later), I thought that this usage warning is the source of the problem. Thanks, Matthias ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: auto_ptr/move issue
David B. Held [EMAIL PROTECTED] wrote in message b1e68m$mqs$[EMAIL PROTECTED]">news:b1e68m$mqs$[EMAIL PROTECTED]... [...] This looks suspiciously like Mojo. [...] Ok, this was perhaps one of the most poorly worded things I've said in a long time (toothpaste discussions nothwithstanding). I didn't mean in any way to imply that Howard was following Andrei around like a vulture stealing his ideas and then taking the credit. I recall Howard being a strong proponent of move semantics months or more before Mojo was ever discussed in public. I simply recognized that Howard had something important to say about move semantics and smart pointers at this time (because he usually has something important to say about move semantics), and I wanted to make sure that I understood what it was. I had already spent time trying to understand Mojo, because I wanted to implement it in SmartPtr. If Mojo was already following the protocol that Howard was promoting, then that was good enough for me. However, if Howard was saying something new that I wasn't catching on to, I wanted to know what it was. So, apologies to Howard if it looked like I was calling him a copycat. That was not my intent in the least. Probably a better way to have asked my question would have been: I plan to implement Mojo in SmartPtr. Does it follow the protocol you propose, or should I consider additional factors not yet discussed? Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Test Tool Proposal (test_tools.hpp)
void checkMyObject(MyObject* my, int context, int a, int b, int c)
{
BOOST_CHECK_EQUAL_MESSAGE(my-getA(), a, context);
BOOST_CHECK_EQUAL_MESSAGE(my-getB(), b, context);
BOOST_CHECK_EQUAL_MESSAGE(my-getC(), c, context);
}
MyObject* my1 = new MyObject(1, 2, 3);
checkMyObject(my1, __LINE__, 1, 2, 3);
MyObject* my2 = new MyObject(4, 5, 6);
checkMyObject(my2, __LINE__, 4, 5, 6);
I believe that message provided by BOOST_CHECK_EQUAL is more valuable, cause
it gives the mismatched values.
When you run in this kind of the situation I would recommend:
1. Use macro instead of function
#define CHECK_MY_OBJECT( obj, vA, vB, vC ) \
BOOST_CHECK_EQUAL(obj-getA(), v1); \
This way want loose line information.
2. use BOOST_MESSAGE tool
void checkMyObject(MyObject* my, int context, int a, int b, int c, size_t
source_line)
{
BOOST_MESSAGE( Testing my-some_kind_of_object_identification() );
// or
BOOST_MESSAGE( Perform check on line: source_line );
BOOST_CHECK_EQUAL(my-getA(), a);
BOOST_CHECK_EQUAL(my-getB(), b);
BOOST_CHECK_EQUAL(my-getC(), c);
}
Regards,
Gennadiy.
P.S. Don't forget to set log level to messages would you decide to choose
the second solution.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]
At 09:46 PM 2/2/2003, Howard Hinnant wrote: Could someone review the motivations for wanting an implicit conversion to T* ? I'm failing to come up with any myself. It is useful when it is desirable for the smart pointer to mimic a built-in pointer as closely as possible. One case where that happens is when making extensive use of a third-party library which passes a lot of arguments as raw pointers. Writing p.get() a great deal tends to make code less readable. Another case is when trying to toughen up legacy code by replacing a raw pointer variable with a smart pointer. Changes are minimized if the smart pointer mimics a raw pointer closely. To me, a major benefit of a policy based design is to be able to accommodate a wide range of features, including those which find only limited use. If a policy based smart pointer can't accommodate a wide range of features, I start to wonder if the design itself is inflexible and flawed. That's why I worry a lot about whether a given PBSP design can handle apparently marginal uses. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Test Tool Proposal (test_tools.hpp)
I've a similiar problem with BOOST_CHECK family, but I think the solution can be different: provide a means to convert failed test into assertion failure. This way I can conveniently debug. Currently, I have to replace BOOST_CHECK with assert manually, to find where the failure happened. Gennadiy, what do you think? - Volodya I do not understand exactly how switching to assert would help you locate the failure point. If you going to run it under debugger you as well could just set a break point on failed assertion. If you going to analize the core using debugger, why not run it under debugger in a first place. If you expect to get a location from the assert output - it will be not better than test tools one. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
Terje Slettebø wrote: From: Vladimir Prus [EMAIL PROTECTED] after having to output std::vector to stream again and again using custom solution, I started to wonder why we don't have a solution in boost. Does it makes sense to include operators for vectors, sets, etc? I was thinking about boost/io/vector.hpp boost/io/set.hpp You can do this quite well using the standard library and stream iterator adapters. This may do both of your approaches above. For example: I certainly know that. std::cout Print vector\n; std::copy(list.begin(),list.end(),Out(std::cout,\n)); And I don't like it in the least. Compared with std::cout new path is v \n; the use of std::copy is way too verbose. BTW, you can't output std::pair that way. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
Al Stevens who writes the C++ column for Doctor Dobbs Journal put out a persistent template library for C++ containers some time back. It is probably on the DDJ web site, although I haven't looked there recently. You might want to check that out and see what he did. I will readily admit I have not had the need to persist container data in my daily programming but I can understand others having that need. Vladimir Prus [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi, after having to output std::vector to stream again and again using custom solution, I started to wonder why we don't have a solution in boost. Does it makes sense to include operators for vectors, sets, etc? I was thinking about boost/io/vector.hpp boost/io/set.hpp and so on. There are basically two approaches: 1. Operators use fixed format: bracked list with commas between values for vector, for example. 2. Manipulators are provided to set brackets and separators. I had implemented the second approach some time ago, but it turned out that was overkill. So, 1) looks better now. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MetaMap (was: [BGL] MutablePropertyGraph questions)
On Mon, 2003-02-03 at 07:18, David B. Held wrote: Where can we see the actual library? here: http://groups.yahoo.com/group/boost/files/associative_list/ Emily ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Test Tool Proposal (test_tools.hpp)
At 12:54 PM 2/3/2003, Rozental, Gennadiy wrote: P.S. Don't forget to set log level to messages would you decide to choose the second solution. Gennadiy, I had to set the log level from the command line recently, and had a hard time finding out how. I did eventually find an explanation in the docs, but it is buried so deep that it took me quite a while to find it. Operation is really a separate topic IMO, and should be separated out, with a link on the top of each of the appropriate pages. --Beman PS: Once I found how to set the log level, it worked well and was quite useful. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] io operations for stl containers?
From: Terje Slettebø [EMAIL PROTECTED] From: Vladimir Prus [EMAIL PROTECTED] after having to output std::vector to stream again and again using custom solution, I started to wonder why we don't have a solution in boost. Does it makes sense to include operators for vectors, sets, etc? I was thinking about boost/io/vector.hpp boost/io/set.hpp and so on. [...] You can do this quite well using the standard library and stream iterator adapters. This may do both of your approaches above. For example: [...] typedef std::ostream_iteratorstd::string Out; std::cout Print vector\n; std::copy(list.begin(),list.end(),Out(std::cout,\n)); Now try the same with std::map std::string, std::vector std::vectorint . With op, it's still one statement. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: io operations for stl containers?
From: Vladimir Prus [EMAIL PROTECTED] Terje Slettebø wrote: From: Vladimir Prus [EMAIL PROTECTED] after having to output std::vector to stream again and again using custom solution, I started to wonder why we don't have a solution in boost. Does it makes sense to include operators for vectors, sets, etc? I was thinking about boost/io/vector.hpp boost/io/set.hpp You can do this quite well using the standard library and stream iterator adapters. This may do both of your approaches above. For example: I certainly know that. I guessed you might. However, the solution seemed like a good match to your question, given that you didn't give any code example of its use. You mentioned outputting a vector to a stream, using custom separators, and that's what this does. std::cout Print vector\n; std::copy(list.begin(),list.end(),Out(std::cout,\n)); And I don't like it in the least. Compared with std::cout new path is v \n; I understand what you mean now. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: auto_ptr/move issue
On Monday, February 3, 2003, at 12:53 PM, David B. Held wrote: So, apologies to Howard if it looked like I was calling him a copycat. That was not my intent in the least. No, I did not read your question that way. No apologies necessary at all. I plan to implement Mojo in SmartPtr. Does it follow the protocol you propose, or should I consider additional factors not yet discussed? I just reread Andrei's Mojo article, at least the part under Application: auto_ptr's Cousin and Mojoed Containers. It looks to me (after a very superficial read) like move_ptr and mojo_ptr are essentially expressing the same idea. In fact, my understanding is that Howard's move_ptr *is* more similar to mojo_ptr than auto_ptr, because auto_ptr has auto_ptr(auto_ptr), which is exactly the thing Howard is crusading against. I'm not sure that the evolutionary taxonomy of this is worth too many more electrons. But I'm happy to have a cool new signature! :-) -Howard *** * * * Do not move from an lvalue with copy syntax. * * * *** ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Minor problem with random::lognormal_distribution
There is a small correction required for lognormal_distribution.
The problem is flagged under GCC3.2
explicit lognormal_distribution(base_type rng,
result_type mean = result_type(1),
result_type sigma = result_type(1))
...
RealType mean() const { return _mean; }
RealType sigma() const { return _sigma; }
should probably read.
RealType mean() const { return _mean; }
RealType sigma() const { return _sigma; }
Michael
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] io operations for stl containers?
From: Vladimir Prus [EMAIL PROTECTED] after having to output std::vector to stream again and again using custom solution, I started to wonder why we don't have a solution in boost. Does it makes sense to include operators for vectors, sets, etc? I was thinking about boost/io/vector.hpp boost/io/set.hpp and so on. There are basically two approaches: 1. Operators use fixed format: bracked list with commas between values for vector, for example. 2. Manipulators are provided to set brackets and separators. I had implemented the second approach some time ago, but it turned out that was overkill. So, 1) looks better now. If this is done as a library, then I think it's best not to have hard-coded brackets and separators. One might use an xalloc() value for each type to output. For example something like: typedef std::pairint,char Map; typedef std::vectorMap MapList; MapList list; // Fill container std::cout boost::io_formatMap(,, [, ]) boost::io_formatMapList(,,\n) list '\n'; This might print: [1, a] [2, b] [3, c] Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Minor problem with random::lognormal_distribution
Michael Stevens [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
There is a small correction required for lognormal_distribution.
The problem is flagged under GCC3.2
explicit lognormal_distribution(base_type rng,
result_type mean = result_type(1),
result_type sigma = result_type(1))
...
RealType mean() const { return _mean; }
RealType sigma() const { return _sigma; }
should probably read.
RealType mean() const { return _mean; }
RealType sigma() const { return _sigma; }
And while we're at it, we shouldn't use leeding underscores on variables;
these are reserved to the compiler.
regards
Thorsten
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: auto_ptr/move issue
Howard Hinnant [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Monday, February 3, 2003, at 12:53 PM, David B. Held wrote: So, apologies to Howard if it looked like I was calling him a copycat. That was not my intent in the least. No, I did not read your question that way. No apologies necessary at all. Nor did I. For the record, Howard and I have been in correspondence for a long time exchanging code and ideas on the move construction issues. He sent me his latest move_ptr code within minutes of my asking him to review Mojo I (that is, before Mojo II). But I'm happy to have a cool new signature! :-) -Howard *** * * * Do not move from an lvalue with copy syntax. * * * *** Hey, *I* copyrighted that! :o))) Andrei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'torissue]
Thanks Beman.
On Monday, February 3, 2003, at 12:50 PM, Beman Dawes wrote:
At 09:46 PM 2/2/2003, Howard Hinnant wrote:
Could someone review the motivations for wanting an implicit
conversion
to T* ? I'm failing to come up with any myself.
It is useful when it is desirable for the smart pointer to mimic a
built-in pointer as closely as possible.
Yup, just exploring where to draw that line between as closely as
possible and too close.
One case where that happens is when making extensive use of a
third-party library which passes a lot of arguments as raw pointers.
Writing p.get() a great deal tends to make code less readable.
Another case is when trying to toughen up legacy code by replacing a
raw pointer variable with a smart pointer. Changes are minimized if
the smart pointer mimics a raw pointer closely.
I find this remarkably analogous to the operator const charT* issue
with early basic_string. We needed that operator for better
compatibility with legacy code using null-terminated char arrays, and
writing s.c_str() all over the place doesn't read as nice. But in the
end, the implicit conversion to const charT* was deemed too error prone
for basic_string.
To me, a major benefit of a policy based design is to be able to
accommodate a wide range of features, including those which find only
limited use.
If a policy based smart pointer can't accommodate a wide range of
features, I start to wonder if the design itself is inflexible and
flawed. That's why I worry a lot about whether a given PBSP design can
handle apparently marginal uses.
That is a strong argument. On the other hand, should a policy be
provided for a configuration that is overly error prone or dangerous?
I think the answer may be yes, but only if there is sufficient
motivation (like a big performance increase). Otherwise, no. Why
needlessly expose your clients to a dangerous interface?
I don't really know on which side of that danger line the implicit
conversion to raw pointer falls.
If we were rebuilding basic_string today, would we want to provide at
least the option of operator const charT* ?
If we were rebuilding auto_ptr today, would we want to provide at least
the option of implicit conversion to raw pointer?
Too demonstrate the danger part, imagine converting this code from raw
pointer to smart_ptr:
void foo()
{
T* p = ...;
//...
delete p;
}
Joe Coder comes in and changes the constructor, but forgets to change
the destructor.
void foo()
{
smart_ptrT, ... p(...);
//...
delete p;
}
This is a run time error if p implicitly converts to a T*, else it is a
compile time error.
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr - Exception safety reprise
David B. Held [EMAIL PROTECTED] wrote in message
news:b1l23n$84a$[EMAIL PROTECTED]...
What can you say about empty member optimization in VC6.5 and later?
Also, do you have any idea why an empty class that inherits from
non-empty bases would be bigger than the sum of the size of the bases?
Obviously, trivial test cases do not show this behaviour, but the
policy_ptr in the sandbox does (though you'll probably have to wait
till Monday afternoon for me to check in the latest version).
We haven't made any intentional changes to our object model in this
area, so VC6 SP5 and later should be the same as earlier.
In some little tests, I am seeing unusual behavior where it looks like
the ZBO is being done in certain cases, but not in others. Simply
reordering the bases causes the size of the class to change. For
example:
class C1 {};
class C2 { int i; };
class C3 {};
class D1 : C1, C2, C3 { int j; }; // sizeof(D1) == 8
class D2 : C3, C1, C2 { int j; }; // sizeof(D2) == 12
I wasn't aware of this quirk before today, so I can't explain it. I
knew we did the ZBO for a single zero size base, but it looks like it
happens in circumstances I wasn't aware of.
As for sizeof(Derived) sum(sizeof all bases), they usual explaination
is alignment. Consider:
class C1 { char c; };
class C2 { int i; };
class C3 { char c; };
class D : C1, C2, C3 {};// sizeof(D) == 12
Because the C2 subobject needs to be 4 byte aligned, there are 3 bytes
of padding b/w C1::c and C2::I in D.
Assuming this isn't the issue you are noticing, you'll need to send me a
preprocessed file and I'll take a look.
--
Jason Shirk
VC++ Compiler Team
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [ublas-dev] Re: abs doesn't work with VC .NET
Hi Michael (hi Kresimir, hi Julius, hi all ;-), you wrote: I have come across this problem before. The same problem occured when I was working on .NET patches for boost::quaternion. So there's at least another boost library affected. The following is from memory of VC7, so actual names may be slightly different. I no longer have access to the MSVC compilers. Luck me!! :-) If turn on compiler warning level 3 you should see warnings for line such as abs(1.5) that a double is being converted to and integer. If look in the math.h header you will see why All the C++ definitions are in there. The problem is that many (includeing abs(float/double) are NOT defined when the macro _MSC_EXTENSIONS is defined. This is for some stupid backwards compatibilty with their previous broken headers!! To make things work, you must either Use the compiler switch /Za to disable microsoft extensions. OR use #ifdef _MSC_EXTENSIONS #undef _MSC_EXTENSIONS #include cmath #define _MSC_EXTENSIONS #else #include cmath #endif I do not recommend /Za. The compiler has even more problems then normal when it is set. VC7 cannot compile uBLAS and many other boost libraries with /Za. This agrees with Julius' statements. My long term solution was simply to edit math.h to remove the offending conditional compilation! :-) The is no specific solution in boost/config for this problem. I don't see there is an easy fix either as _MSC_EXTENSIONS needs to be define for some of MS own header files. OK. I've prepared the following patch for ublas: - Add the following to the MSVC section of ublas/config.hpp #ifdef _MSC_EXTENSIONS #define BOOST_UBLAS_NO_CMATH #endif - Change the problematic parts of ublas/traits.hpp to #if defined (BOOST_NO_STDC_NAMESPACE) || defined (BOOST_UBLAS_NO_CMATH) return ::fabsf (t); #else return std::abs (t); #endif I'll commit this later, if noone objects. Thanks, Joerg ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Rewritten Rationale for shifted_ptr
1) I have rewritten the Rationale section of shifted_ptr in file /shifted_ptr/doc/structboost_1_1shifted__ptr.html: http://groups.yahoo.com/group/boost/files/shifted_ptr.zip 2) I have taken a look at some garbage collector routines and they all use placement operator new (). The best way to start sharing those objects between different smart pointer types would simply be to use parallel heaps, until a new C++ syntax takes the lead. 3) Little presentation of myself: - 25 years old. - B. Sc. Computer Science, University of Sherbrooke. - Internet Connection Wizard / Utils of some Linux distro. - Image synthesis is my favorite study. 4) BTW I think Boost is pretty impressive as a discussion forum. It's funny sometimes. Thanks to Boost's team. Regards, Philippe A. Bouchard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/movec'tor issue]
Beman Dawes [EMAIL PROTECTED] writes:
At 09:46 PM 2/2/2003, Howard Hinnant wrote:
To me, a major benefit of a policy based design is to
be able to accommodate a wide range of features,
including those which find only limited use.
If a policy based smart pointer can't accommodate a
wide range of features, I start to wonder if the design
itself is inflexible and flawed. That's why I worry a
lot about whether a given PBSP design can handle
apparently marginal uses.
There's no reason we have to be restricted to a single idiom AFAICT.
The GenVoca-style design we're using for the new iterator_adaptors is
great for adding new interface in the most-derived class. A blend of
techniques is often more effective than trying to cram everything into
a single approach. If you want a smart_ptr with implicit conversion,
one way might be:
template class T
struct legacy_ptr
: smart_ptrblah, blah, blah...
{
legacy_ptr(T* p) : smart_ptrblah...(p) {}
T* operator()() const { return this-get(); }
};
-Ddave
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Minor problem with random::lognormal_distribution
At 02:26 PM 2/3/2003, Thorsten Ottosen wrote:
Michael Stevens [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
There is a small correction required for lognormal_distribution.
The problem is flagged under GCC3.2
explicit lognormal_distribution(base_type rng,
result_type mean = result_type(1),
result_type sigma = result_type(1))
...
RealType mean() const { return _mean; }
RealType sigma() const { return _sigma; }
should probably read.
RealType mean() const { return _mean; }
RealType sigma() const { return _sigma; }
And while we're at it, we shouldn't use leeding underscores on variables;
these are reserved to the compiler.
Only in the global namespace. 17.4.3.1.2 says:
Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.
^^
--Beman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Test Tool Proposal (test_tools.hpp)
Gennadiy, I had to set the log level from the command line recently, and had a hard time finding out how. I did eventually find an explanation in the docs, but it is buried so deep that it took me quite a while to find it. The was a request couple month ago (by David Held if I am not mistaken) to add some kind of usage/help ability to Boost.Test CLA. That was yet another reason for me to address it with generic cla framework. Once it will be done you wont need to look into the docs to get cla descriptions. Currently cla descriptions are on Unit Test Framework page. I may move it closer to the docs entrance. Or I could provide direct link from first page. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Array support [was SmartPtr (Loki) -auto_ptr/movec'torissue]
On Monday, February 3, 2003, at 02:44 PM, Andrei Alexandrescu wrote: Howard Hinnant [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Sunday, February 2, 2003, at 11:40 PM, Andrei Alexandrescu wrote: By and large, I believe smart pointers to arrays are an oxymoron and should not be supported. Why? The reasons are explained in MC++D. Here's my take: Seems I've been going back to reread sections of my trusty MDC++D quite often lately. :-) 1. Arrays of polymorphic objects don't work. Right. But to me that just means you don't want to have the member template converting constructors/assignment in your array version of the smart pointer (as shown in boost::shared_ptr/shared_array, and the move_ptr example at http://home.twcny.rr.com/hinnant/Utilities/move_ptr). 2. If I wanna arrays of monomorphic objects I can use std::vector. True. 3. If I wanna arrays of monomorphic objects and std::vector's performance is unsatisfactory to me, Naw, couldn't happen! ;-) I can use the typed buffers (http://www.moderncppdesign.com/publications/cuj-08-2001.html, http://www.moderncppdesign.com/publications/cuj-10-2001.html, http://www.moderncppdesign.com/publications/cuj-12-2001.html) that are present in the up-and-coming YASLI. Up-and-coming? I was just getting used to legendary! :-) 4. So there's no reason I'd ever wanna have smart pointers to arrays. I agree that vector (or vector-like substitutes) are preferred over smart_ptrT[] in most circumstances. But there are times when ownership of the array needs to be transferred or shared. In those instances, vector is not a good fit. smart_ptrvectorT is a possibility, but this is typically inferior both in performance, and in client level syntax (e.g. (*p)[i] instead of p[i]). Example 1: I currently have a requirement in one of my classes that it: 1. Be constructible from a null terminated char array of arbitrary length. 2. Have a member function that returns the string which the object was constructed with. 3. Have a no-throw copy constructor. These requirements can be neatly met by having the class hold a shared pointer (reference counted, cyclic, whatever) to an array of char. Example 2: A routine whose function is to create and fill a dynamically sized array and then transfer ownership of that array back to the client. A strstream-like object might want to do this. It could create and fill the buffer as needed, and then transfer ownership of that buffer to the client. -Howard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
- Original Message - From: Andrei Alexandrescu [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 03, 2003 8:44 PM Subject: [boost] Re: Array support [was SmartPtr (Loki) -auto_ptr/movec'torissue] Howard Hinnant [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Sunday, February 2, 2003, at 11:40 PM, Andrei Alexandrescu wrote: By and large, I believe smart pointers to arrays are an oxymoron and should not be supported. Why? The reasons are explained in MC++D. Here's my take: 1. Arrays of polymorphic objects don't work. 2. If I wanna arrays of monomorphic objects I can use std::vector. 3. If I wanna arrays of monomorphic objects and std::vector's performance is unsatisfactory to me, I can use the typed buffers (http://www.moderncppdesign.com/publications/cuj-08-2001.html, http://www.moderncppdesign.com/publications/cuj-10-2001.html, http://www.moderncppdesign.com/publications/cuj-12-2001.html) that are present in the up-and-coming YASLI. 4. So there's no reason I'd ever wanna have smart pointers to arrays. I needed something with exactly boost::shared_array's interface to add reference counting to ublas. With shared_array I'm able to run the CLAPACK test suite on ublas containers. Best, Joerg ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
[EMAIL PROTECTED] (Joerg Walter) writes: I needed something with exactly boost::shared_array's interface to add reference counting to ublas. With shared_array I'm able to run the CLAPACK test suite on ublas containers. I think Ralf Grosse-Kunstleve did something similar in scitbx (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/array_family/) -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]
At 02:57 PM 2/3/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
At 09:46 PM 2/2/2003, Howard Hinnant wrote:
To me, a major benefit of a policy based design is to
be able to accommodate a wide range of features,
including those which find only limited use.
If a policy based smart pointer can't accommodate a
wide range of features, I start to wonder if the design
itself is inflexible and flawed. That's why I worry a
lot about whether a given PBSP design can handle
apparently marginal uses.
There's no reason we have to be restricted to a single idiom AFAICT.
The GenVoca-style design we're using for the new iterator_adaptors is
great for adding new interface in the most-derived class. A blend of
techniques is often more effective than trying to cram everything into
a single approach. If you want a smart_ptr with implicit conversion,
one way might be:
template class T
struct legacy_ptr
: smart_ptrblah, blah, blah...
{
legacy_ptr(T* p) : smart_ptrblah...(p) {}
T* operator()() const { return this-get(); }
};
Yes, that's a good point for add-on features that can be implemented on top
of smart_ptr.
--Beman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]
Rozental, Gennadiy [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] I would like to second this opinion. I do not see a big of a deal in enforcing get() for direct access. It may make transition to SP slightly more difficult. But the advantages IMO prevail. Well, offering implicit conversion through a policy doesn't seem to be causing any problems, so I don't see why it shouldn't be offered as an option for people who really really want it, and are willing to take the risks associated. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost/mpl/integral_c.hpp and Borland
Fernando Cacciola [EMAIL PROTECTED] writes: - Original Message - From: David Abrahams [EMAIL PROTECTED] To: Beman Dawes [EMAIL PROTECTED] Cc: boost [EMAIL PROTECTED]; Aleksey Gurtovoy [EMAIL PROTECTED]; Fernando Cacciola [EMAIL PROTECTED] Sent: Friday, January 31, 2003 9:58 PM Subject: [boost] Re: boost/mpl/integral_c.hpp and Borland Beman Dawes [EMAIL PROTECTED] writes: Dave, Your change to boost/mpl/integral_c.hpp broke a lot of Borland 5.61 compiles. I thought something like that might happen on the broken compilers. I don't really know what the best approach here might be, other than to take out casts for those compilers. I'm not even sure if integral_csome_enum,... (which is what the change accomodates) is appropriate. Perhaps we should have enum_c with no next,prior for this purpose. I see that integral_c has been fixed now. I'm puzzled though about why the apparently simple fix didn't worked on Borland. On bcc5.5.1, it says: Cannot cast from 'T' to 'T' (!?) What happens if you replace it with a C-style cast? Anyway, I'd like to know what is the role of integral_c; in particular, with respect to 'int_c'. int_c is a convenience that prevents you from having to write integral_cint, ... IOWs, why does it has next/prior? That one's for Aleksey. I know that you could pass an integral_c to a metafunction which would operate on a generic Integral metavalue, doing ::next for instance; but my question is: when and why would you pass 'integral_c' instead of 'int_c'? If you want unsigned long, signed char, unsigned short, etc... values. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Current is_convertible borken for bcc5.5.1
Hi, I was just about to build the filesystem library for the first time on my Win98+BCC 5.5.1 environment, but I got lots of errors from type_traits/is_convertible.hpp Since the regression_test shows that this library passed bcc5.6.1 yesterday, I thought that is_convertible might have changed today. Indeed, version 1.10 (the previous) works fine. (that is, I was able to build the FS library) I attach here the compiler output using the -Q compiler option (which shows extended error information). Fernando Cacciola Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland ..\src\exception.cpp: Error E2396 C:\boost\boost\boost/type_traits/is_convertible.hpp 190: Template argument must be a constant expression in function filesystem::path::end() const + Full parser context + ..\src\exception.cpp, line 21: #include C:\boost\boost\boost\filesystem\exception.hpp + C:\boost\boost\boost\filesystem\exception.hpp, line 23: #include C:\boost\boost\boost/filesystem/path.hpp + C:\boost\boost\boost/filesystem/path.hpp, line 23: namespace boost + C:\boost\boost\boost/filesystem/path.hpp, line 25: namespace filesystem + C:\boost\boost\boost/filesystem/path.hpp, line 53: class filesystem::path + C:\boost\boost\boost/filesystem/path.hpp, line 135: decision to instantiate: iterator_adaptorfilesystem::detail::path_itr_imp,default_iterator_policies,std::string,const std::string ,const std::string *,std::bidirectional_iterator_tag,int filesystem::path::end() const + --- Resetting parser context for instantiation... + C:\boost\boost\boost/filesystem/path.hpp, line 108: parsing: iterator_adaptorfilesystem::detail::path_itr_imp,default_iterator_policies,std::string,const std::string ,const std::string *,std::bidirectional_iterator_tag,int filesystem::path::end() const + ..\src\exception.cpp, line 21: #include C:\boost\boost\boost\filesystem\exception.hpp + C:\boost\boost\boost\filesystem\exception.hpp, line 23: #include C:\boost\boost\boost/filesystem/path.hpp + C:\boost\boost\boost/filesystem/path.hpp, line 16: #include C:\boost\boost\boost/iterator_adaptors.hpp + C:\boost\boost\boost/iterator_adaptors.hpp, line 138: namespace boost + C:\boost\boost\boost/iterator_adaptors.hpp, line 816: decision to instantiate: iterator_adaptorfilesystem::detail::path_itr_imp,default_iterator_policies,std::string,const std::string ,const std::string *,std::bidirectional_iterator_tag,int + --- Resetting parser context for instantiation... + ..\src\exception.cpp, line 21: #include C:\boost\boost\boost\filesystem\exception.hpp + C:\boost\boost\boost\filesystem\exception.hpp, line 23: #include C:\boost\boost\boost/filesystem/path.hpp + C:\boost\boost\boost/filesystem/path.hpp, line 16: #include C:\boost\boost\boost/iterator_adaptors.hpp + C:\boost\boost\boost/iterator_adaptors.hpp, line 138: namespace boost + C:\boost\boost\boost/iterator_adaptors.hpp, line 560: namespace detail + C:\boost\boost\boost/iterator_adaptors.hpp, line 691: decision to instantiate: iterator_adaptor_traits_genfilesystem::detail::path_itr_imp,std::string,const std::string ,const std::string *,std::bidirectional_iterator_tag,int + --- Resetting parser context for instantiation... + ..\src\exception.cpp, line 21: #include C:\boost\boost\boost\filesystem\exception.hpp + C:\boost\boost\boost\filesystem\exception.hpp, line 23: #include C:\boost\boost\boost/filesystem/path.hpp + C:\boost\boost\boost/filesystem/path.hpp, line 16: #include C:\boost\boost\boost/iterator_adaptors.hpp + C:\boost\boost\boost/iterator_adaptors.hpp, line 138: namespace boost + C:\boost\boost\boost/iterator_adaptors.hpp, line 560: namespace detail + C:\boost\boost\boost/iterator_adaptors.hpp, line 640: decision to instantiate: make_argvalue_type_tag,std::string + --- Resetting parser context for instantiation... + ..\src\exception.cpp, line 21: #include C:\boost\boost\boost\filesystem\exception.hpp + C:\boost\boost\boost\filesystem\exception.hpp, line 23: #include C:\boost\boost\boost/filesystem/path.hpp + C:\boost\boost\boost/filesystem/path.hpp, line 16: #include C:\boost\boost\boost/iterator_adaptors.hpp + C:\boost\boost\boost/iterator_adaptors.hpp, line 124: #include C:\boost\boost\boost/compressed_pair.hpp + C:\boost\boost\boost/compressed_pair.hpp, line 20: #include C:\boost\boost\boost/detail/compressed_pair.hpp + C:\boost\boost\boost/detail/compressed_pair.hpp, line 23: #include C:\boost\boost\boost/type_traits/object_traits.hpp + C:\boost\boost\boost/type_traits/object_traits.hpp, line 18: #include C:\boost\boost\boost/type_traits/has_trivial_assign.hpp + C:\boost\boost\boost/type_traits/has_trivial_assign.hpp, line 15: #include C:\boost\boost\boost/type_traits/is_pod.hpp + C:\boost\boost\boost/type_traits/is_pod.hpp, line 15: #include C:\boost\boost\boost/type_traits/is_scalar.hpp + C:\boost\boost\boost/type_traits/is_scalar.hpp, line 14: #include
[boost] Re: Smart pointers: One more implementation + question
Pavel Vasiliev [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I would like to offer for discussion one more implementation of reference counting smart pointer. [snip] Howgh! Andrei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Smart pointers: One more implementation + question
Andrei Alexandrescu [EMAIL PROTECTED] writes: Pavel Vasiliev [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I would like to offer for discussion one more implementation of reference counting smart pointer. [snip] Howgh! Andrei How do you pronounce that? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] is_class
- Original Message -
From: Daniel Frey [EMAIL PROTECTED]
This not only leads to safer class detection, it also allows us to
implement is_member_function without providing versions for every number
of parameters.
This is already possible. The specialization...
R C::*
...matches all pointers-to-members, including pointers-to-member-functions.
However, when it *does* match a pointer-to-member-function, the type of 'R' is a
function type. Therefore, it is possible to detect a pointer-to-member-function
like this:
templateclass struct is_pointer_to_member_function {
enum { value = false };
};
templateclass R, class C struct is_pointer_to_member_functionR C::* {
enum { value = is_samevoid (R), void (R*)::value };
};
...since only function types are implicitly adjusted to pointer-to-function when
used as a parameter.
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_class
On Tue, 04 Feb 2003 00:23:26 +0100, Paul Mensonides wrote:
- Original Message -
From: Daniel Frey [EMAIL PROTECTED]
template class C, typename T struct is_member_function_pointer T
C::*
{ enum { value = is_function T ::value }; };
template class C, typename T struct is_member_function_pointer T
C::*
const { enum { value = is_function T ::value }; };
template class C, typename T struct is_member_function_pointer T
C::*
volatile { enum { value = is_function T ::value }; };
template class C, typename T struct is_member_function_pointer T
C::*
const volatile { enum { value = is_function T ::value }; };
Whoa, sorry Daniel, I missed this part, which is almost exactly the same
as my post.
And which is exactly the kind of type-deduction that the GCC fails to do
- which is why I needed to create the slightly more complex version to tame
both compilers at the same time :)
Regards, Daniel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Rewritten Rationale for shifted_ptr
David B. Held [EMAIL PROTECTED] wrote in message b1mruf$o2u$[EMAIL PROTECTED]">news:b1mruf$o2u$[EMAIL PROTECTED]... [...] It took me a while to find the Rationale section. If you look at most other Boost libraries, you'll see that the documentation has a very specific layout. The first page of your documentation is not very helpful, and finding things like the rationale or overview is needlessly difficult. Instead of making the generated docs the focus of your documentation, maybe you should take the time to make the main part of your docs look like other Boost libraries. index.html now contains the main documentation. Sorry for the trouble. Philippe A. Bouchard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Borland specific defects : new config defines?
Most my porting to borland recently has involved a couple of new bugs introduced in BCB6. Rather than testing compiler and version everywhere, should I instead create some BOOST_SOME_DEFECT macros in the borland config file and test for those instead? If so, any suggestions for the macro names would be appreciated. The two defects are: The various std::isdigit, islower, isalnum etc. convenience functions will not compile. The fix in this case is to simply implement the function directly via use_facet instead e.g: std::use_facetstd::ctypeCh ( oss_.rdbuf()-getloc() ).is( std::ctype_base::digit, c ) [Also note in the general case it may be necessary to remove_const on the character type] Second problem is with the STLport implementation of the STL. This places all std names into the namespace _STL and uses macro-magic to make this look like std. Unfortunately, for reason I have not fully determined, that magic sometimes comes up short. Often the fix is to add a using directive: using std::swap; swap( a, b ); Sometimes the fix is to explicitly specify namespace _STL instead. _STL::swap( a, b ); There are cases where either fix works, and specific cases where only one form or the other works. As best I can figure, these macros should be defined #if defined(__BORLAND__)\ __BORLANDC__ = 0x0560 \ __BORLANDC__ = 0x0561 In the latter case we should test that the STLport library has been chosen as well. Are either of these cases already covered by another existing workaround? Do either of these problems look familiar to users of other compilers? [Note: I have not tested with the Kylix compiler but suspect it will have similar issues] -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] io operations for stl containers?
From: Glenn G. Chappell [EMAIL PROTECTED] Vladimir Prus wrote: after having to output std::vector to stream again and again using custom solution, I started to wonder why we don't have a solution in boost. Does it makes sense to include operators for vectors, sets, etc? ... std::cout new path is v \n; The philosophy behind the STL would suggest accessing containers through their iterators. Something like std::cout new path is Foo(v.begin(), v.end()) \n; would not be too bad (and it would be even better if it were called something besides Foo). This would be very general, while remaining quite readble, I think. Delimiters could be set using optional parameters, among other methods. std::cout new path is Foo(v.begin(), v.end(), [, ,, ]) \n; You then still have the issue of what to do with the element types. For example: std::vectorstd::pairchar,int v; std::cout Foo(v.begin(),v.end(),[,,,]) '\n'; How to print each element, and what if you want different delimiters for the elements? Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
--- Larry Evans [EMAIL PROTECTED] wrote: The type implemented in shared_plain.h (in the directory above) is a reference All I see there doesn't include shared_plain.h unless it's in a subdirectory. Is it some other place? Sorry, this is the correct link: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/scitbx/include/scitbx/array_family/ Ralf P.S.: If you look around some more and find more missing header files: these are automatically generated by a set of Python scripts under the control of SCons. -- My high-tech replacement for the pre-processor library. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Array support [was SmartPtr (Loki)-auto_ptr/movec'torissue]
--- David Abrahams [EMAIL PROTECTED] wrote: I did not use boost::shared_array to implement the shared_plainT type because one of our requirements is that one reference count can be used to manage multiple types. Sounds like a job for a policy-based smart pointer to array to me ;-) This could well be. However: - I don't think this was an option a year ago when I started the array family (weak excuse). - The reference counting object is implemented in exactly 44 lines of code. I am afraid a policy based approach could easily involve typedef expressions twice the size (I know I am a bit vicious here). Having said that, a little overhead could be more than justified if the boost smart pointer is thread-safe, as I believe it is now. My shared_plain type does not include any code to specifically support threaded applications (I am counting on Python to get this right for me). Ralf __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
