Subject: Re: [boost] [uuid] Interface
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-19 05:10:52
>> ... > No. The input iterator constructs from the raw octets, expecting them
> as in 4.1.2. Layout and Byte Order
Well, I obviously confused the construction from a string and the construction from the raw octets. Quite embarassing. My mind is obviously already chasing that Christmas goose.
> I'm still not convinced that that providing the default constructor is
> such a bad thing, so I would still like Andy's #define to allow it.
I'd like the default constructor as well. Very much in fact. The problem is that our expectations of what that constructor needs to do are quite different.
The behavior of the default constructor that you'd like to see (apologies if I got it wrong) is to create an invalid uuid. I feel that is not the canonical use of the default constructor. Indeed, that usage of the default constructor *not* to actually create an object has become quite popular. It does not make it right though. I find it unfortunate and hackish.
I feel that the default constructor should indeed construct... with all the default "parameters"... as the language prescribes... as other constructors do. In uuid context it'd be to let the OS/infrastructure decide what is best. That way we'd achieve the best portability without sactificing the quality and I am sure for that reason it'll be the most popular deployment. That's why I'd like that behavior assigned to the simplest available (default) constructor. I do not want to be forced to choose a certain generator just to discover it is not supported on another platform. Having said that I do not see my view getting far. In that case, I'd prefer not to have the default cnstr at all as IMHO it sends the wrong message and enforces the wrong programming practice. Just my view, of course.
OK, I guess, it is indeed time for me to tune out and get into that Christmas spirit. Happy Christmas and Happy New Year everyone (pick whichever appropriate).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk