- Boost - lists.preview.boost.org

Re: [boost] [UUID] Code for UUIDs as PODs and other changes
by Vladimir Batov 07 Dec '08

07 Dec '08

Scott, Many thanks for your crash-course on aggregates and your patence with me. Much and truly appreciated. I had to dig the Standard up for a "refreshment". It's embarassing but I admit I all forgot about that "C" stuff tucked away in a corner of C++. I never thought I'd come across it ever again. Kudos to you for your effort. I am coming to appreciate your implementation. It's very impressive how efficiently you managed to cut off "all the excess" and how far you've got without C++ "perks and whistles". I am sure it had its uses. That said, I feel aggregates' limitations are far too restrictive for a full-fledged implementation (and especially the interface). Best, Vladimir. > ... > It comes from making it a POD, as all PODs are also aggregates. > > 8.5.1 Aggregates [dcl.init.aggr] > > An aggregate is an array or a class (clause 9) with no user-declared > constructors (12.1), no private or protected non-static data members > (clause 11), no base classes (clause 10), and no virtual functions > (10.3). When an aggregate is initialized the initializer can contain > an initializer-clause consisting of a brace-enclosed, comma-separated > list of initializer-clauses for the members of the aggregate, written > in increasing subscript or member order. If the aggregate contains > subaggregates, this rule applies recursively to the members of the > subaggregate.

1 0

Re: [boost] [UUID] Code for UUIDs as PODs and other changes
by Vladimir Batov 07 Dec '08

07 Dec '08

... > >> uuid u = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */ > >> 0x6b, 0xa7, 0xb8, 0x14, > >> 0x9d, 0xad, > >> 0x11, 0xd1, > >> 0x80, 0xb4, > >> 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 > >> }; > > > > I am not sure as a user I'd be interested in doing that kind of low-level stuff and in fact I am doubtful it'll even compile. > > > > It does work, actually. I use it to implement > uuids::namespaces::dns() and friends. It compiles indeed! Tried MSVC++9 and even ol' gcc 3.4.4. C++0X talks about initialization of that kind but for standard containers. To me it feels like very non-standard behavior. What am I missing? Someone help me out here. > 4.1.7. Nil UUID > > The nil UUID is special form of UUID that is specified to have all > 128 bits set to zero. > > I'm not particularly attached to nil(), but at the same time, I don't > have any better name. I dislike null(), when people are used to > treating NULL as pointer (even when it actually isn't). C# uses > Empty, but that's also not great, since empty is strongly entrenched > through its use in the Container concept. Fair enough. The standard expicitly mentioning uuid::nil() sounds like a good reason. > Really, I'd be plenty happy to get rid of it entirely, since value > initialization provides the same functionality: uuid id = uuid(); Have to disagree as to me the above is unclear as I am not sure if it means "create a new uuid" or "create an invalid uuid". I prefer saying clearly what I mean, i.e. uuid id(uuid::nil()); Best, Vladimir.

2 1

Re: [boost] [UUID] Code for UUIDs as PODs and other changes
by Vladimir Batov 07 Dec '08

07 Dec '08

> PODness: I am personally far from thrilled and fail to see benefits of that move. > As a POD, all the constructors are of course gone. Well, "constructors are of course *not* gone" as the default and copy constructors will be generated for you. The auto-generated default constructor does not seem to initialize the underlying boost::array to anything. Therefore, I suspect "uuid id;" will be left uninitialized. > ... > I don't think that serialization to and from strings > belongs in the type, and it seems like using a lexical_cast is > perfectly reasonable: Yes, taking out the conversions to/from string certainly make the UUID-related code/interface cleaner. More so, IMHO lexical_cast has become somewhat idiomatic for that kind of tasks and provides the well-defined and well-known path to enable the functionality. Much preferred. > ... > I don't know if it's useful, but aggregate syntax also opens > possibilities: > > uuid u = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */ > 0x6b, 0xa7, 0xb8, 0x14, > 0x9d, 0xad, > 0x11, 0xd1, > 0x80, 0xb4, > 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 > }; I am not sure as a user I'd be interested in doing that kind of low-level stuff and in fact I am doubtful it'll even compile. I see nil() introduced in the code with "As named in RFC 4112, 4.1.7" comment. I tried googling for "RFC 4112" and it gave me "RFC4112 - Electronic Commerce Modeling Language (ECML) Version" with no "nil" mentioned. I have no issues with "nil" pre se as it's well-entrenched in other languages. However, I feel that C/C++ settled on "null" (and C++ 0x introduces nullptr). So, I fail to see any reasons to deviate from that. >> ... the rest snipped. I see a lot of code cleanup, reorganization and reshuffling. Everything has its place and time. Even though I agree that at some point it needs to be done, I do not feel we've reached that point. I'd much prefer to focus on providing well-thought-through interface. Without having agreed on the interface and settling on what and how certain functionality is delivered to the user I feel that "implementation-detail" discussions seem premature and in fact distracting at this point. Best, Vladimir.

2 1

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir.Batov＠wrsa.com.au 07 Dec '08

07 Dec '08

> ... > Hmm, I looked at some other value types in boost and this is what I > found. > > boost::gregorian::date() creates an 'not_a_date_time'. > One can exclude this constructor with a #define. > boost::posix_time::ptime() is the same as above > boost::function() is initialized as empty > std::string() is initialized as empty > boost::numeric::interval() the created interval is the singleton zero > boost::quaternion() initialized each component/member to the default > values for their type (i.e. zero for floating numbers) > boost::optional() is uninitialized > boost::rational() is 'zero' Some usages are legitimate (like an empty std::string is still a string and boost::rational() default initialization to 0). Some usages are IMHO mildly confusing (like boost::function()) as there is a clear understanding that it has to have some function, i.e. no-function is clearly invalid. Some others are IMHO unfortunate and quite confusing -- does boost::gregorian::date() mean 'not_a_date_time' or boost::gregorian::date() means 'now'? My view is that the interface needs to be intuitive. With the date I would not probably use the default constructor at all as it is not immediately clear what it does. Instead I'd have boost::date::invalid() and boost::date::now(). Deploying the default constructor for something apart from default construction is a hack unfortunately abused quite often. It does not make it right though. > ... > And, what should the default constructor do? Create a null uuid or a > unique one? It feels like you are struggling to associate the default constructor with something. :-) You know, you really do not have to. The default constructor has quite a clear meaning. If a class has no functionality matching that meaning, that class should not be defining the default constructor and should not be hijacking that constructor for anything else. Convenient? Sure. Good API? Hmm, I am not sure -- a good interface should be saying what it means. > ... > This is what I want to prevent as well. I'm concerned about the user > who does: > boost::uuid u; // this create a unique uuid > and does not realize that they just ran a computational intensive > function when they didn't need or want to. I am not sure what there is not to realize? The language is clear that "boost::uuid u" calls the default constructor... whatever that constructor does (intensive or not). Treating object creation as it were built-in types (i.e. created uninitialized/invalid) is wrong, encourages the wrong programming practice and expectations and should not be encouraged. > ... > Fair. These people are likely either doing: > > boost::uuid u = get_uuid_from_somewhere(); // eg from database > > or > > boost::uuid u; > get_uuid_from_somewhere(u); // eg from database > > The second case would create a unique uuid unless they remembered to do: > boost::uuid u(boost::uuid::null()); There is a big difference between #1 and #2 and the language is lucidly clear what the difference is -- #1 does just one step and creates and object from another object; #2 does 2 steps -- creates an object with the default constructor and then applies operator=(). Painting over that difference and encouraging user's ignorance of that important subtlety (for a novice) won't do anyone any good. > It sounds very easy for one to forget. This doesn't change symentics, > it is just less efficient. It *does* change semantics and it does change execution flow and the language cannot be any clearer on that. If you mean #1, then instead of making #2 to behave like #1, I'd prohibit #2 altogether by not providing the default constructor. Having said that to *me* "boost::uuid id;" makes sense as I read it as the language describes -- I create a UUUID with the default constructor. My interpretation of it is that I trust the implementer to do the right thing for me -- the user. I'd say, if that interpretation is subtle and really controversial, just get rid of the default constructor altogether. In the end, it's just my view. I am not prepared to die fighting for it. :-) Thanks, Vladimir.

4 3

A design for geometric objects
by Mathias Gaunard 06 Dec '08

06 Dec '08

The past discussions on geometric libraries focused on how to define points. What matters even more however is how geometric objects are designed. There is a natural subtyping relationship between geometric objects. Deriving a square from a rectangle is usually frowned upon in OOP, because it can easily break the Liskov Substitution Principle if the objects are mutable. Making them immutable, however, solves the issue altogether. Morever, by using static subtyping, e.g. with concepts, we have multiple dispatch for free and don't pay any performance overhead, making such a design much better than with OOP. Concepts being non-intrusive, a mutable object may well be implemented but the concept can be a read-only view. Note that while I'm talking about concepts, I don't necessarily mean C++0x concepts, it could also be an alternative system. I would like to be able to write generic algorithms for geometric objects. Say I write an algorithm for any simple polygon. That algorithm should work with any simple quadrilateral, simple triangle, a rectangle, etc. Then I rewrite the same algorithm for convex polygons. So non-convex simple polygons should invoke the old algorithm, and convex ones the new one. So a system to find best matches is required. If we consider the subtyping graph for rectangle (which is not the most complex object, but certainly is complex enough to expose a complex graph), here is what we get: Rectangle < Right-angled Trapezium < Trapezium < ConvexQuadrilateral < Parallelogram < Trapezium ConvexQuadrilateral < SimpleQuadrilateral < Quadrilateral < Polygon < ConvexPolygon < SimplePolygon SimplePolygon < InsideSimplePolygonalLine SimplePolygon < Polygon Polygon < PolygonHole < Curve Polygon < InsidePolygonalLine InsideSimplePolygonalLine < InsideSimpleClosedCurve InsideSimplePolygonalLine < InsidePolygonalLine < InsideClosedCurve InsideSimpleClosedCurve < InsideClosedCurve < Curve SimpleClosedCurve < ClosedCurve < Curve InsideSimpleClosedCurve -> SimpleClosedCurve (composition thingy) InsideClosedCurve -> ClosedCurve (composition thingy) Curve < Object For clarification, a curve is here defined as the image of a continuous map from a real interval to the space. That is to say any set of points that is "connected". A simple curve is a curve that doesn't cross itself (just like simple polygons), which means the the map is injective, and a closed curve is a curve where the application comes from a closed interval and where the image is the same on both boundaries. A closed simple curve is a closed curve that is injective but for the boundaries. InsideClosedCurve defines the space with is "inside" a closed curve, which could also be defined by another map (known as a space-filling curve, but they are harder to manipulate, at least for polygons). A Polygon is an InsideClosedCurve with the closed curve being line segments within a plan. A PolygonHole is a Polygon which may have holes themselves defined by closed curves. An Object is a possibly (likely, even) infinite set of points in space. There is quite a complexity and redundancy here. It would be nice if it was possible to enhance that somehow. And that graph probably isn't fully complete, for example "right-angled" should probably be made separate propriety from trapezium. Also there should probably be Polytope somewhere. And PolygonHole lacks specializations too. The worse is the Inside thingies. I suppose having template concepts of some kind could help. Therefore I am wondering if there is any way to make the design simpler and more elegant. Indeed, such a design seems hard to maintain, it doesn't scale so well, and if I want to include something in there I probably have to modify other concepts as well. A geometric object is really just a set of proprieties. Working with meta-functions like is_quadrilateral, is_convex or is_simple seems like less work and verbosity. But how can such a system provide subtyping and best matches? Any comments and ideas are welcome.

7 29

[python] Python 3.0
by Robert Dailey 06 Dec '08

06 Dec '08

Will Boost.Python 1.37 work with the Python 3.0 library?

4 6

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir Batov 06 Dec '08

06 Dec '08

> ... > All in all my impression of the *current* situation with the proposal is > that at *present* we have many useful and promising bits and pieces lying > around. I see good ideas. I see good suggestions. I fail to see the > product. It surely is a good start but to me we have not reached the > destination yet. I'd be more comfortable after I see those bits and pieces > taking shape. For me that shape primarily would be the interface and the > documentation -- the initial pieces of the contract between the user and > the implementor. Once both parties are happy with the contract, you'll > beaver away providing the content/implementation. Now that I looked at the code once again, I think I'd like to take back the "bits and pieces lying around" bit (as it feels plain wrong and I think I need better glasses to see things the first time around :-)). In fact, I feel that all the pieces are more/less in place and I'll be very much in content if I see something along the following lines: namespace boost { class uuid { struct time_generator; struct random_generator; struct best_generator; template<class Generator> uuid(Generator const&) {...} or template<class Generator> uuid(Generator const& =best_generator()) {...} static uuid null() { ... } typedef void (base::*bool_type)(); void internal_bool() {}; operator bool_type() const { return *this == null() ? 0 : &base::internal_bool; } ... }; struct uuid::time_generator { ... }; struct uuid::random_generator { ... }; struct uuid::best_generator { ... }; } // boost Replacing is_null() with the implicit "bool" converter is not a syntactic sugar. It's very much idiomatic along the same lines as "a + b" is better than "a.add(b)". I'd probably look at deploying Boost.Range functionality as I see many constructors working with ranges. With that caveat I think I am all willing to abandon my original (a very lonely BTW) position and run over to the happy 'yes' campers. Thanks, Vladimir.

2 1

Re: [boost] [UUID] Code for UUIDs as PODs and other changes
by Scott McMurray 06 Dec '08

06 Dec '08

On Sat, Dec 6, 2008 at 14:07, Roman Yakovenko <roman.yakovenko(a)gmail.com> wrote: > On Sat, Dec 6, 2008 at 11:10 AM, Scott McMurray <me22.ca+boost(a)gmail.com> wrote: >> I remarked the other day that a UUID has a well-defined, portable >> binary format, so I took a bit of time to rearrange things to make the >> UUID class a POD and make more use of the generators idea. Along the >> way I made a few other changes. >> >> I've uploaded the result (with updated docs) to the vault as >> uuid_alt_v13_pod.zip : >> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=uuid_a… >> >> Some elaboration follows below. Comments appreciated. > > Hi. Very nice implementation. I have few question: > Thanks, though most of the implementation credit still goes to Andy. > 1. Why variant() and version() are member function of class uuid? I > think they should be free functions. > Either way would work, obviously. I thought of them as properties of the UUID, rather than some computed thing, but that's an iffy difference, so for normal encapsulation justifications it may better to make them non-member. > 2. May be it is better to introduce "native_generator" which is cross platform? > There is actually a typedef for that. I figured that it would be better to keep the implementations separate and conditionally compile the typedef, rather than try to mix the 2 (or more, if other platforms) implementations into one. That said, strategies would also work nicely for that, and would allow cross-platform specification of which UUID version you'd like, too...

2 2

[shared_ptr] Two suggestions for the aliasing constructor
by Clive Jones 06 Dec '08

06 Dec '08

1) An aliasing constructor that takes an rvalue reference Motivating example: in my code I have a utility function... template <typename T, typename Y> boost::shared_ptr<T> shared_ptr_to_member(const boost::shared_ptr<Y> &ptr, T Y::*ptr_to_member) { return boost::shared_ptr<T>(ptr, &(ptr.get()->*ptr_to_member)); } ...which seems to me a prime candidate for having an overload that takes an rvalue reference. The implementation would be very simple, by direct analogy with the existing aliasing constructor and rvalue constructor. template< class Y > shared_ptr( shared_ptr<Y> && r, T * p ): px( p ), pn() // never throws { pn.swap( r.pn ); r.px = 0; } 2) Refactor the pointer_cast functions to use the aliasing constructor The pointer casting functions were implemented before the aliasing constructor was available; using it, simpler implementation is possible. For example, rewriting static_pointer_cast as: template<class T, class U> shared_ptr<T> static_pointer_cast(shared_ptr<U> const & r) { return shared_ptr<T>(r, static_cast<T *>(r.get())); } ...allows the removal of boost::detail::static_cast_tag and the shared_ptr constructor that accepts it. Regards, --Clive.

1 0

[UUID] Code for UUIDs as PODs and other changes
by Scott McMurray 06 Dec '08

06 Dec '08

I remarked the other day that a UUID has a well-defined, portable binary format, so I took a bit of time to rearrange things to make the UUID class a POD and make more use of the generators idea. Along the way I made a few other changes. I've uploaded the result (with updated docs) to the vault as uuid_alt_v13_pod.zip : http://www.boostpro.com/vault/index.php?action=downloadfile&filename=uuid_a… Some elaboration follows below. Comments appreciated. ~ Scott PODness: As a POD, all the constructors are of course gone. This doesn't bother me, but I have no idea what others will think. In fact, I like it better, since I don't think that serialization to and from strings belongs in the type, and it seems like using a lexical_cast is perfectly reasonable: uuid u = lexical_cast<uuid>("21f7f8de-8051-5b89-8680-0195ef798b6a"); This cuts out a large chunk of code, too. I don't know if it's useful, but aggregate syntax also opens possibilities: uuid u = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */ 0x6b, 0xa7, 0xb8, 0x14, 0x9d, 0xad, 0x11, 0xd1, 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 }; In a possibly controversial move, I changed everything that could throw exceptions. That's not that much, though. The std::string parsing code I had already removed, which was the only source of one exception. The other came from the byte input iterator range constructor, which I kept as an assign member function (though I made mutable iterators available, so it's unnecessary). In there I switched the throw to an assert, assuming that it's reasonable for people to arrange for there to always be 16 elements as a precondition, since it's raw construction (which is used into the generators, for example) rather than something likely to come from user input. Include cost: I took the opportunity to move the stream I/O code out to its own header, like the serialization code is. This means that the uuids/uuid.hpp header is fairly light, as the <locale> and <string> includes are gone. In fact, all that's left are these: #include <boost/array.hpp> #include <boost/assert.hpp> #include <boost/config.hpp> #include <boost/cstdint.hpp> #include <boost/numeric/conversion/cast.hpp> #include <boost/static_assert.hpp> Generators: I liked the idea of using a generator object for the random UUIDs, so I wanted to extend that idea. I renamed it to random_generator, on the theory that random_generator<> isn't strenuous if a user wants the default PRNG. boost::uuids::random_generator<> gen1; boost::uuids::uuid u1 = gen1(); boost::lagged_fibonacci44497 rng; boost::uuids::random_generator<boost::lagged_fibonacci44497&> gen2(rng); boost::uuids::uuid u2 = gen2(); For name-based, I introduced a sha1_generator class. This is seeded with a namespace UUID (those from the RFC are provided in boost::uuids::namespaces), and then has an operator() that takes a byte input iterator range. It may be interesting to add a boost.range overload, allowing the generator to be used as a transform functor for strings. boost::uuids::sha1_generator gen(boost::uuids::namespaces::dns()); std::string name = "www.widgets.com"; boost::uuid u = gen(name.begin(), name.end()); Native UUIDs: I recall that someone in the review wanted an interface to the OS functionality, and I had been looking at Linux's earlier, so I wrote up 2 additional generators. e2fsprogs_generator uses the <uuid/uuid.h> header and libuuid on Linux, and passes all the tests that random_generator does. windows_generator uses UuidCreate, and is completely untested. Variants and Versions: I thought being able to find out these might be a good idea, so they're there too. enum variant_type {variant_ncs = 0, variant_dce = 1, variant_rfc_4122 = variant_dce, variant_microsoft = 2, variant_other = 3}; variant_type variant() const; enum version_type {version_wrong_variant = -1, version_unknown = 0, version_1 = 1, version_time_based = version_1, version_2 = 2, version_dce_security = version_2, version_3 = 3, version_name_based_md5 = version_3, version_4 = 4, version_random = version_4, version_5 = 5, version_name_based_sha1 = version_5}; version_type version() const; Implementation Details: I switched sha1.hpp over to using int32_t to remove the 4-byte-int requirement. I also let it handle 512 MiB+ messages (if size_t can), though that's not a serious concern. I replaced the *reinterpret_cast<unsigned long*> in random_generator with the kind of code used in sha1 that doesn't have the endianness dependence or what I think is an aliasing violation.

1 0

lexical_cast optimization
by David Abrahams 06 Dec '08

06 Dec '08

Someone was asking me today about the inefficiency of lexical_cast for its common itoa/atoi-like usage, and it occurred to me that it could *easily* be optimized to handle the common cases by dispatching to itoa/atoi ftoa/atof where available, and even sprintf. Seems like a great idea to me. Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

9 9

[interprocess] default constructors
by Jan Stetka 06 Dec '08

06 Dec '08

Hi, Is there any reason why named_mutex and managed_shared_memory don't have a default constructor?

6 24

Running Boost Regression Tests
by frederic.bron＠alcan.com 05 Dec '08

05 Dec '08

I have tried to run the regression tests but I seem unsuccessful. My machine is a linux RHE4 x86_64 (Linux vorace0 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:32:02 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux). I wanted to test compiler intel 10.0 and g++ 3.4.6 (have also 4.1.0 but the name is g++4 and I do not know how to make boost understand it exists). Here is what I did: 1. downlowd run.py 2. python run.py --runner=bronf --platform=linux_x86_64 --tag=trunk --toolsets=gcc-3.4.6,intel-linux-10.0 I obtained the attached output (run.log) which ends with: # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 60, in ? runner(root) File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 189, in __init__ self.main() File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 542, in main getattr(self,action_m)() File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 507, in command_regression self.command_test() File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 313, in command_test self.command_test_boost_build() File "/soft/bal/usr/builds/boost_test/tools_regression_src/regression.py", line 350, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/soft/bal/usr/builds/boost_test/results/boost/bin.v2/libs/any/test/any_test.test' Any clue? F. Bron (See attached file: run.log) Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

5 36

n2427 atomic implementation?
by vicente.botet 05 Dec '08

05 Dec '08

Hi, Can the N2427 - C++ Atomic Types and Operations be implemented without the help of the compiler? Do some one have a partial implementation? Vicente

5 10

[config] BOOST_ALL_DYN_LINK comment in user.hpp
by Michael Marcin 05 Dec '08

05 Dec '08

The comment in boost/config/user.hpp gives 2 examples, both of which appear to be invalid. ------------------------------ // BOOST_ALL_DYN_LINK: Forces all libraries that have separate source, // to be linked as dll's rather than static libraries on Microsoft Windows // (this macro is used to turn on __declspec(dllimport) modifiers, so that // the compiler knows which symbols to look for in a dll rather than in a // static library). Note that there may be some libraries that can only // be statically linked (Boost.Test for example) and others which may only // be dynamically linked (Boost.Threads for example), in these cases this // macro has no effect. // #define BOOST_ALL_DYN_LINK ------------------------------ I believe Boost.Test can now be linked dynamically and Boost.Threads can now be linked statically. -- Michael Marcin

1 0

[Serialization] this seems wrong
by Kenny Riddile 05 Dec '08

05 Dec '08

I'm somewhat inexperienced with boost serialization, so forgive me if I'm just missing something. I have a few simple classes that are all serializable. In each class's header, I have BOOST_CLASS_EXPORT( ClassName ) right after the class declaration. All of these classes are header-only, so there is no cpp. All of these classes are very similar, so the statement above is often on the same line of the file (line 21 in this case). When I include all of these headers in a single source file, I get errors like this: 1>Win32WindowImpl.cpp 1>c:\subversion\trunk\vfx\platform\include\messages\minimized.hpp(21) : error C2371: 'vfx::platform::`anonymous-namespace'::boost_serialization_guid_initializer_21' : redefinition; different basic types 1> c:\subversion\trunk\vfx\platform\include\messages\close.hpp(21) : see declaration of 'vfx::platform::`anonymous-namespace'::boost_serialization_guid_initializer_21' 1>c:\subversion\trunk\vfx\platform\include\messages\restored.hpp(21) : error C2371: 'vfx::platform::`anonymous-namespace'::boost_serialization_guid_initializer_21' : redefinition; different basic types 1> c:\subversion\trunk\vfx\platform\include\messages\close.hpp(21) : see declaration of 'vfx::platform::`anonymous-namespace'::boost_serialization_guid_initializer_21' I walked down into the BOOST_CLASS_EXPORT macro and saw that the BOOST_CLASS_EXPORT_GUID macro appends the line number (notice the 21's in the above compiler output) to what it generates. Thinking to myself, "this will never work", I simply went and added empty lines to the header files so that the BOOST_CLASS_EXPORT( ClassName ) was on a different line in each and everything compiled. Am I missing something? Is this fixed in 1.37 (I'm currently forced to use 1.36). If I wanted white-space to matter, I would be writing python :)

6 16

[MPL] new run-time algorithm: for_all
by George van Venrooij 05 Dec '08

05 Dec '08

Hello everyone, I recently created a MPL-based run-time algorithm named "for_all" which you can find at the following location: http://tinyurl.com/5a9d9d It is based on the "for_each" algorithm. The main difference is that it traverses a sequence of sequences and constructs new sequences that are then passed to a functor. Read the article for more information. I found it to be very useful in several cases, so I wanted to share it with the community. If you have any comments or spot any problems, please let me know. Regards, George ------------------------------------------------------------------------ George van Venrooij Organic Vectory http://www.organicvectory.com

5 13

boost::interprocess::bad_alloc in copy ctor of slist
by Christoph Mathys 05 Dec '08

05 Dec '08

Hi! I have an object containing an interprocess slist (wrapped in a simple template) which I first construct outside shared memory. Then I want to push_front this object into a slist lying inside shared memory. And I get an interprocess::bad_alloc exception from the lists copy constructor. If I don't use the slist's copy ctor but something like this->assign(x.begin(), x.end()), the code runs through (the list was always empty in the test). I use gcc 4.2.4 on linux 2.6.24 (ubuntu 8.04). Boost 1.36 What am I doning wrong? Christoph Following the throwing code: #include <boost/interprocess/containers/vector.hpp> #include <boost/interprocess/containers/slist.hpp> #include <boost/interprocess/allocators/allocator.hpp> #include <boost/interprocess/managed_shared_memory.hpp> using namespace boost::interprocess; managed_shared_memory* getSegment() { static managed_shared_memory segment(create_only, "MySharedMemory", 65536); return &segment; } template<typename T> struct my_slist { typedef allocator<T, managed_shared_memory::segment_manager> ShmemAllocator; typedef slist<T, ShmemAllocator> List; my_slist() : m_list(ShmemAllocator(getSegment()->get_segment_manager())) { } void push_front(const T& obj) { m_list.push_front(obj); } List m_list; }; struct ListHolder { my_slist<int> m_slist; }; typedef my_slist<ListHolder> HolderList; int main() { shared_memory_object::remove("MySharedMemory"); HolderList *holderlist = getSegment()->construct<HolderList>("IntListHolderList")(); ListHolder asdf; holderlist->push_front(asdf); // exception boost::interprocess::bad_alloc return 0; }

2 3

Boost compilation warnings and errors with XLC 10.1 on AIX 5.3
by Ioannis Papadopoulos 05 Dec '08

05 Dec '08

Hi, When compiling Boost with XLC 10.1 on AIX 5.3, I have the following errors and warnings: Errors: [Math] "libs/math/build/../src/tr1/acosh.cpp", line 11.39: 1540-0403 (S) "acosh(double)" is already defined. "/usr/vacpp/include/math.h", line 843.23: 1540-0425 (I) "acosh" is defined on line 843 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 112.28: 1540-0424 (I) "acosh" is declared on line 112 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 138.21: 1540-0424 (I) "acosh" is declared on line 138 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 755.21: 1540-0424 (I) "acosh" is declared on line 755 of "/usr/include/math.h". "libs/math/build/../src/tr1/asinh.cpp", line 11.39: 1540-0403 (S) "asinh(double)" is already defined. "/usr/vacpp/include/math.h", line 855.23: 1540-0425 (I) "asinh" is defined on line 855 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 116.28: 1540-0424 (I) "asinh" is declared on line 116 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 142.21: 1540-0424 (I) "asinh" is declared on line 142 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 756.21: 1540-0424 (I) "asinh" is declared on line 756 of "/usr/include/math.h". "libs/math/build/../src/tr1/atanh.cpp", line 11.39: 1540-0403 (S) "atanh(double)" is already defined. "/usr/vacpp/include/math.h", line 867.23: 1540-0425 (I) "atanh" is defined on line 867 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 120.28: 1540-0424 (I) "atanh" is declared on line 120 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 146.21: 1540-0424 (I) "atanh" is declared on line 146 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 757.21: 1540-0424 (I) "atanh" is declared on line 757 of "/usr/include/math.h". "libs/math/build/../src/tr1/cbrt.cpp", line 11.39: 1540-0403 (S) "cbrt(double)" is already defined. "/usr/vacpp/include/math.h", line 879.23: 1540-0425 (I) "cbrt" is defined on line 879 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 124.28: 1540-0424 (I) "cbrt" is declared on line 124 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 150.21: 1540-0424 (I) "cbrt" is declared on line 150 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 758.21: 1540-0424 (I) "cbrt" is declared on line 758 of "/usr/include/math.h". "libs/math/build/../src/tr1/copysign.cpp", line 13.39: 1540-0403 (S) "copysign(double, double)" is already defined. "/usr/vacpp/include/math.h", line 891.23: 1540-0425 (I) "copysign" is defined on line 891 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 128.28: 1540-0424 (I) "copysign" is declared on line 128 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 154.21: 1540-0424 (I) "copysign" is declared on line 154 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 293.16: 1540-0424 (I) "copysign" is declared on line 293 of "/usr/include/math.h". "libs/math/build/../src/tr1/erfc.cpp", line 11.39: 1540-0403 (S) "erfc(double)" is already defined. "/usr/vacpp/include/math.h", line 915.23: 1540-0425 (I) "erfc" is defined on line 915 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 136.28: 1540-0424 (I) "erfc" is declared on line 136 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 162.21: 1540-0424 (I) "erfc" is declared on line 162 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 738.21: 1540-0424 (I) "erfc" is declared on line 738 of "/usr/include/math.h". "libs/math/build/../src/tr1/erf.cpp", line 11.39: 1540-0403 (S) "erf(double)" is already defined. "/usr/vacpp/include/math.h", line 903.23: 1540-0425 (I) "erf" is defined on line 903 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 132.28: 1540-0424 (I) "erf" is declared on line 132 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 158.21: 1540-0424 (I) "erf" is declared on line 158 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 737.21: 1540-0424 (I) "erf" is declared on line 737 of "/usr/include/math.h". "libs/math/build/../src/tr1/acoshl.cpp", line 11.44: 1540-0403 (S) "acoshl(long double)" is already defined. "/usr/vacpp/include/math.h", line 846.28: 1540-0425 (I) "acoshl" is defined on line 846 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 114.33: 1540-0424 (I) "acoshl" is declared on line 114 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 140.21: 1540-0424 (I) "acoshl" is declared on line 140 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 317.21: 1540-0424 (I) "acoshl" is declared on line 317 of "/usr/include/math.h". "libs/math/build/../src/tr1/asinhl.cpp", line 11.44: 1540-0403 (S) "asinhl(long double)" is already defined. "/usr/vacpp/include/math.h", line 858.28: 1540-0425 (I) "asinhl" is defined on line 858 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 118.33: 1540-0424 (I) "asinhl" is declared on line 118 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 144.21: 1540-0424 (I) "asinhl" is declared on line 144 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 321.21: 1540-0424 (I) "asinhl" is declared on line 321 of "/usr/include/math.h". "libs/math/build/../src/tr1/atanhl.cpp", line 11.44: 1540-0403 (S) "atanhl(long double)" is already defined. "/usr/vacpp/include/math.h", line 870.28: 1540-0425 (I) "atanhl" is defined on line 870 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 122.33: 1540-0424 (I) "atanhl" is declared on line 122 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 148.21: 1540-0424 (I) "atanhl" is declared on line 148 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 327.21: 1540-0424 (I) "atanhl" is declared on line 327 of "/usr/include/math.h". "libs/math/build/../src/tr1/cbrtl.cpp", line 11.44: 1540-0403 (S) "cbrtl(long double)" is already defined. "/usr/vacpp/include/math.h", line 882.28: 1540-0425 (I) "cbrtl" is defined on line 882 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 126.33: 1540-0424 (I) "cbrtl" is declared on line 126 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 152.21: 1540-0424 (I) "cbrtl" is declared on line 152 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 330.21: 1540-0424 (I) "cbrtl" is declared on line 330 of "/usr/include/math.h". "libs/math/build/../src/tr1/copysignl.cpp", line 11.44: 1540-0403 (S) "copysignl(long double, long double)" is already defined. "/usr/vacpp/include/math.h", line 894.28: 1540-0425 (I) "copysignl" is defined on line 894 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 130.33: 1540-0424 (I) "copysignl" is declared on line 130 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 156.21: 1540-0424 (I) "copysignl" is declared on line 156 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 334.21: 1540-0424 (I) "copysignl" is declared on line 334 of "/usr/include/math.h". "libs/math/build/../src/tr1/erfcl.cpp", line 11.44: 1540-0403 (S) "erfcl(long double)" is already defined. "/usr/vacpp/include/math.h", line 918.28: 1540-0425 (I) "erfcl" is defined on line 918 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 138.33: 1540-0424 (I) "erfcl" is declared on line 138 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 164.21: 1540-0424 (I) "erfcl" is declared on line 164 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 340.21: 1540-0424 (I) "erfcl" is declared on line 340 of "/usr/include/math.h". "libs/math/build/../src/tr1/erfl.cpp", line 11.44: 1540-0403 (S) "erfl(long double)" is already defined. "/usr/vacpp/include/math.h", line 906.28: 1540-0425 (I) "erfl" is defined on line 906 of "/usr/vacpp/include/math.h". "./boost/math/tr1.hpp", line 134.33: 1540-0424 (I) "erfl" is declared on line 134 of "./boost/math/tr1.hpp". "/usr/vacpp/include/math.h", line 160.21: 1540-0424 (I) "erfl" is declared on line 160 of "/usr/vacpp/include/math.h". "/usr/include/math.h", line 342.21: 1540-0424 (I) "erfl" is declared on line 342 of "/usr/include/math.h". [Spirit] "./boost/graph/detail/read_graphviz_spirit.hpp", line 165.28: 1540-0600 (S) The reference to "var" is ambiguous. "./boost/spirit/home/classic/phoenix/primitives.hpp", line 221.1: 1540-0425 (I) "phoenix::var" is defined on line 221 of "./boost/spirit/home/classic/phoenix/primitives.hpp". "./boost/spirit/home/classic/phoenix/primitives.hpp", line 237.1: 1540-0424 (I) "phoenix::var" is declared on line 237 of "./boost/spirit/home/classic/phoenix/primitives.hpp". "/usr/include/sys/var.h", line 59.8: 1540-0425 (I) "var" is defined on line 59 of "/usr/include/sys/var.h". "./boost/graph/detail/read_graphviz_spirit.hpp", line 142.5: 1540-0700 (I) The previous message was produced while processing "boost::detail::graph::dot_grammar::definition<boost::spirit::scanner<boost::spirit::multi_pass<std::istream_iterator<char,char,std::char_traits<char>,long>,boost::spirit::multi_pass_policies::input_iterator,boost::spirit::multi_pass_policies::ref_counted,boost::spirit::multi_pass_policies::buf_id_check,boost::spirit::multi_pass_policies::std_deque>,boost::spirit::scanner_policies<boost::spirit::skip_parser_iteration_policy<boost::detai...". "./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp", line 178.24: 1540-0700 (I) The previous message was produced while processing "boost::spirit::impl::grammar_helper<boost::spirit::grammar<boost::detail::graph::dot_grammar,boost::spirit::parser_context<boost::spirit::nil_t> >,boost::detail::graph::dot_grammar,boost::spirit::scanner<boost::spirit::multi_pass<std::istream_iterator<char,char,std::char_traits<char>,long>,boost::spirit::multi_pass_policies::input_iterator,boost::spirit::multi_pass_policies::ref_counted,boost::spirit::multi_pass_policies::buf_id_check,...". "./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp", line 251.29: 1540-0700 (I) The previous message was produced while processing "boost::spirit::impl::get_definition<boost::detail::graph::dot_grammar,boost::spirit::parser_context<boost::spirit::nil_t>,boost::spirit::scanner<boost::spirit::multi_pass<std::istream_iterator<char,char,std::char_traits<char>,long>,boost::spirit::multi_pass_policies::input_iterator,boost::spirit::multi_pass_policies::ref_counted,boost::spirit::multi_pass_policies::buf_id_check,boost::spirit::multi_pass_policies::std_deque>,boost::spiri...". "./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp", line 296.29: 1540-0700 (I) The previous message was produced while processing "boost::spirit::impl::grammar_parser_parse<0,boost::detail::graph::dot_grammar,boost::spirit::parser_context<boost::spirit::nil_t>,boost::spirit::scanner<boost::spirit::multi_pass<std::istream_iterator<char,char,std::char_traits<char>,long>,boost::spirit::multi_pass_policies::input_iterator,boost::spirit::multi_pass_policies::ref_counted,boost::spirit::multi_pass_policies::buf_id_check,boost::spirit::multi_pass_policies::std_deque>,boos...". "./boost/spirit/home/classic/core/non_terminal/grammar.hpp", line 57.14: 1540-0700 (I) The previous message was produced while processing "boost::spirit::grammar<boost::detail::graph::dot_grammar,boost::spirit::parser_context<boost::spirit::nil_t> >::parse_main<boost::spirit::scanner<boost::spirit::multi_pass<std::istream_iterator<char,char,std::char_traits<char>,long>,boost::spirit::multi_pass_policies::input_iterator,boost::spirit::multi_pass_policies::ref_counted,boost::spirit::multi_pass_policies::buf_id_check,boost::spirit::multi_pass_policies::std_deque>,boost::spir...". "./boost/spirit/home/classic/core/non_terminal/grammar.hpp", line 65.9: 1540-0700 (I) The previous message was produced while processing "boost::spirit::grammar<boost::detail::graph::dot_grammar,boost::spirit::parser_context<boost::spirit::nil_t> >::parse<boost::spirit::scanner<boost::spirit::multi_pass<std::istream_iterator<char,char,std::char_traits<char>,long>,boost::spirit::multi_pass_policies::input_iterator,boost::spirit::multi_pass_policies::ref_counted,boost::spirit::multi_pass_policies::buf_id_check,boost::spirit::multi_pass_policies::std_deque>,boost::spirit::s...". "libs/graph/src/read_graphviz_spirit.cpp", line 33.6: 1540-0700 (I) The previous message was produced while processing "boost::detail::graph::read_graphviz(std::istream &, mutate_graph &)". Warnings: "libs/regex/src/../src/regex_traits_defaults.cpp", line 350.56: 1540-0804 (W) The characters "/*" are detected in a comment. "libs/regex/src/../src/regex_traits_defaults.cpp", line 545.47: 1540-0804 (W) The characters "/*" are detected in a comment. "./boost/thread/pthread/mutex.hpp", line 30.9: 1540-0198 (W) The omitted keyword "private" is assumed for base class "boost::noncopyable". "./boost/thread/pthread/mutex.hpp", line 78.9: 1540-0198 (W) The omitted keyword "private" is assumed for base class "boost::noncopyable".

1 0

[interprocess] named_condition
by Jan Stetka 05 Dec '08

05 Dec '08

The program stops running when it reaches cond.wait(...); This works ok when its compiled on its own but not with the rest of my code. boost::interprocess::named_mutex nm(boost::interprocess::create_only,"STOP_PH_MTX"); boost::interprocess::named_condition cond(boost::interprocess::create_only,"STOP_PH_CND"); boost::interprocess::scoped_lock<boost::interprocess::named_mutex> stop_ph_lock(nm); cond.wait(stop_ph_lock); boost::interprocess::named_mutex::remove("STOP_PH_MTX"); boost::interprocess::named_condition::remove("STOP_PH_CND");

2 2

Breaking existing libraries
by Tomas Puverle 04 Dec '08

04 Dec '08

You may or may not have noticed a thread I started on boost.users about the breaking changes to Boost.Range. Here’s a short summary: We are currently (firmwide) using boost 1.33.1. I am in the process of trying to migrate and test some of our apps with boost 1.37. In 1.35 there was a breaking change to Boost.Range with respect to how singular ranges behave. This brings up several issues: 1) The breakage was silent. The interface stayed the same but the behavior changed, and drastically so. 2) No communation: While I don’t usually post to boost.devel/boost.user, I and my colleagues still read it. Nobody recalls any mention of this on the list. Searching gmane brings up nothing, either. 3) No documentation on the boost website. As far as I can see, this change was introduced in 1.35 this March. On http://www.boost.org/users/news/version_1_35_0, there is no mention of a breaking change to Boost.Range. 4) The new Boost.Range behaves differently in debug and release builds. The public function is_singular() always returns false in release builds even when it would return true in debug builds. Apart from the fact that this change breaks a lot of our code and obsoletes several useful (necessary?) idioms, the manner in which it happened is far below the standards that one has come to expect from boost. At the moment, I have to say I don’t have a good answer to how to fix our code. However, I would at least like to try to make sure this kind of silent breakage doesn’t happen again. Tom

28 86

[graph] 'short' in bundled property throws boost::bad_any_cast
by remi.chateauneu＠gmx.de 04 Dec '08

04 Dec '08

Hi, I have a graph with a bundled property whose one of the members is a 'short'. When calling read_graphml, it throws an exception: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_any_cast> >' what(): boost::bad_any_cast: failed conversion using boost::any_cast Same problem with 'unsigned short'. With 'int' and 'long', it works.

2 2

[interprocess] maximum length for names of mutexes, memory segments etc.
by JOAQUIN M. LOPEZ MUÑOZ 04 Dec '08

04 Dec '08

A component of Boost.Flyweight called intermodule_holder internally uses some Boost.Interprocess objects with very long names intended to guarantee sistem-wide uniqueness. For instance, this is how such an internal mutex can be named (87 chars): boost_flyweight_intermodule_holder_mutex_5660_601342046_2913549788_3054690985_591945496 Alas seems like 87 chars is too much in some platforms like NetBSD: terminate called after throwing an instance of 'boost::interprocess::interprocess_exception' what(): File name too long See http://tinyurl.com/6m693p . This problem also shows in some of Boost.Inteprocess own tests for NetBSD. Is there any maximum length we can safely commit to across allplatforms? (docs are silent wrt this). Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

[interprocess] preparing containers
by Thorsten Ottosen 04 Dec '08

04 Dec '08

Hi Ion, Some of my students tried to use boost::circular_buffer with Boost.Interprocess allocators. Apparently the docs does not mention circular_buffer as one that is compatible with Boost.Interproccess. What do we need to do to make a container that support the special allocators? In particular, if I want to use boost::ptr_vector, then do I need to have stateful allocators (both the normal container allocator, and the clone_allocator)? Thanks -Thorsten

4 10

Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
by Deane Yang 04 Dec '08

04 Dec '08

Joe Gottman wrote: > Deane Yang wrote: >> Edward Diener wrote: >>> Deane Yang wrote: >>>> >>>> I have an even more extreme view on this. I don't believe any >>>> arithmetic operations should be permitted for constrained numbers. >>>> They just don't make sense (would you ever want to add two different >>>> days of a month?). >>> >>> You have chosen a particular type for which arithmetic operations >>> sometimes make little sense. In many other situations this is not the >>> case. >> >> >> Could you give an example? > > > One example: adding 2 to Monday to get Wednesday, or adding 2 to > Saturday to get Monday. > > But that does not correspond to the built-in arithmetic operation. This is modular arithmetic in disguise, so wouldn't make more sense to use a modular integer class (integers mod 7) and represent the days of the week using the numbers 0 to 6?

2 1