On Tue, Dec 23, 2008 at 01:24, Vladimir Batov <batov@people.net.au> wrote:
Just for clarity I'll state the obvious -- in your example 'm_uuid' *is* initialized. Only built-in types allow declaration without definition (as a place holder). Classes do not allow that behavior. Classes always require and call constructors.
"Declaration without definition" is extern. I think you mean uninitialized, which *is* allowed in classes, if they're aggregates. I've already uploaded a version that does exactly that.
Therefore, IMHO making them *look* like they behave similarly to built-ins sends/enforces the wrong message/impression.
So why not make them behave like them? I've always heard "do as the ints do" as the guideline for value types.
Therefore, I prefer the following which does exactly the same -- 'm_uuid' initialized invalid -- but explicit about what it actually does.
[code snip]
As for efficiency I expect this variant to be at least as efficient (if not better) because uuid::nil() is likely to have and to return the same initialized-once instance
I'd be very suspicious of that claim. The cache miss for going to get that instance could well be worse.
i.e. no byte initialization traversal
If you allow a constructor for making the nil value (obviously I would like the default constructor, but a function pointer so you could do uuid(uuids::nil) would be fine in your way), then there's no need for uuid::nil() to have a loop, since it can value-initialize the member array (which is an aggregate) letting the compiler use the most efficient zeroing method it has. Also, in a situation where the constructor logic is unneeded, it's possible to completely remove one that simply value-initializes. The compiler can never remove calls to a global static PRNG (which has cache and threading consequences, too).