On Tue, Dec 23, 2008 at 20:10, Vladimir Batov <batov@people.net.au> 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?
could be overloaded to call lexical_cast<uuid<aggregate> >, the fastest option. People could have map<string, uuid<nil_default> > if
Amusingly, "null" is listed as a synonym for "invalid" (in http://thesaurus.reference.com/browse/invalid ). "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> they want the "if (m[foo])" shortcut. And you could have uuid<native_generator>. The obvious question, then, is whether that's overkill :P ~ Scott