On Sat, Dec 6, 2008 at 21:12, Vladimir Batov <batov@people.net.au> wrote:
...
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.
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. Boost.Array is also an aggregate (http://www.boost.org/doc/libs/1_37_0/doc/html/array/rationale.html), so the initializer works by initializing the subaggregate, with the excess braces elided following 8.5.1/11. Value-initialization of unspecified members (8.5.1/7) gives another way to get the nil UUID: uuid u = {}; assert(!u); (These rules are also why I removed the boost.operators usage, since even empty base classes run afoul.)
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());
True. If the review has made anything clear, it's that explicit is best. Best, ~ Scott