Boost logo

Boost :

Subject: Re: [boost] [uuid] Interface
From: Scott McMurray ([hidden])
Date: 2008-12-23 21:08:30

On Tue, Dec 23, 2008 at 20:10, Vladimir Batov <batov_at_[hidden]> wrote:
>> I don't really have any strong objections to your description insofar
>> as it applies to char* in the context of "C Strings", but I completely
>> disagree with extending it to uuid.
> Yes, I think I've explained that my usage of it is mostly historical and
> habitual. Also, we've established that "invalid" is not the ideal
> description. Still, I cannot see anyone coming out with a better name to
> classify nil, null and the like. Until then, I guess, I'll probably keep
> using "invalid" (not in spite but merely as the closest *I* can come up
> with). Consider my usage of it in broader sense (as you did with pointers).
> By now we all understand in what context it is used and we can put this one
> to rest -- we still have plenty to debate about, right?

Amusingly, "null" is listed as a synonym for "invalid" (in ). "Specious" is close
to working, and borrowing "singular" from iterators almost fits, but I
can't come up with a great name either.

And I think the problem here is that we really don't have that much to
debate about (which isn't really a problem, I suppose). The only
thing we disagree about is what the default constructor should do,
which is why we started debating about whether the nil UUID was
"invalid", since we all (as far as I can tell) agree that a default
constructor shouldn't put something in an invalid state, just not what
was "invalid".

To rephrase the big problem I have with making the default constructor
call a generator: to me, it feels like making shared_ptr<T>() do the
same as shared_ptr<T>(new T()). Sure, you could do it. Sure, it
saves people calling new themselves. Sure, you could then have
shared_ptr<T>::null() for the null pointer. And I think it could even
be done without breaking a fairly large fraction of programs. But
nobody would *ever* advocate that. It'd just be a weird thing to do.

But there's always the other way to resolve a disagreement over
semantics: parametrization!

What if there was an initialization policy? boost::uuid could be
boost::uuids::uuid<no_default>, since I think there are a fairly large
number of use cases that don't need one at all. lexical_cast<uuid<T>
> could be overloaded to call lexical_cast<uuid<aggregate> >, the
fastest option. People could have map<string, uuid<nil_default> > if
they want the "if (m[foo])" shortcut. And you could have

The obvious question, then, is whether that's overkill :P

~ Scott

Boost list run by bdawes at, gregod at, cpdaniel at, john at