December 2008 - Boost - lists.preview.boost.org

a invites you to join Zorpia
by a 07 Dec '08

07 Dec '08

Hi boost! Your friend a from , just invited you to his online photo albums and journals at Zorpia.com. So what is Zorpia? It is an online community that allows you to upload unlimited amount of photos, write journals and make friends. We also have a variety of skins in store for you so that you can customize your homepage freely. Join now for free! Please click the following link to join Zorpia: http://me.signup.zorpia.com/signup?invitation_key=20081054ec30c646c05fcf5cc… This message was delivered with the a's initiation. If you wish to discontinue receiving invitations from us, please click the following link: http://me.signup.zorpia.com/email/optout/boost@lists.boost.org

1 0

Boost-docs moderation
by Vladimir Prus 07 Dec '08

07 Dec '08

Who's in charge of moderating boost-docs mailing list? I've posted a few messages already that are reported to be sent to moderation queue, and did not appear yet. Direct mail to boost-docs-owner(a)lists.boost.org appear to have no effect either. Thanks, Volodya

2 2

[constrained_value] default initialization
by Jeff Flinn 07 Dec '08

07 Dec '08

I couldn't find mention of what is the initial value of bounded_int<int, 123, 456>::type some_var; I assume it follows the rules for an int? The Simple constrained objects examples says the following is legal: even_int a; What about: odd_int b; Thanks, Jeff

2 1

Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
by Robert Kawulak 07 Dec '08

07 Dec '08

> From: Neal Becker > There is confusion over bounded vs. bounded_int. Maybe > rename bounded_int to compile_time_bounded, or static_bounded. I'm not against changing the name if something better than bounded_int is proposed. However, compile_time_bounded is longish and may be interpreted as checking the bounds at compile time, while static_bounded may suggest that some static members are involved. What do others think?

1 0

[Serialize] error 'unable to start program' with demo.cpp compiled in debug mode under msvc7.1
by David Körner 07 Dec '08

07 Dec '08

Hi, when I compile the demo.cpp from the boost.serialize tutorial in release mode everything works fine. But when I compile it in debug mode the application wont start and the error 'unable to start program' is displayed. It further says that the application has failed to start because the configuration is incorrect. When I change something and do a recompile - the compiler fails: 'unable to update manifest. wrong parameter'. I then have to do a clean+rebuild and it compiles again but wont run until I comment out every boost.serialize code. I use MSVC7.1 (VS2005). I already have used the serialize library with boost version 1.34 successfully. Can someone help me with that issue? Has anybody experienced similar problems? Any help or hint would be appreciated. Thank you very much in advance. David _________________________________________________________________ Wer erfand den Glückskeks? Kleiner Tipp: Die Chinesen waren es nicht! - Mehr auf msn.de http://redirect.gimas.net/?n=M0812xMSNDE

3 3

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