Re: [boost] [uuid] Interface

Subject: Re: [boost] [uuid] Interface
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2008-12-19 12:47:16

On Fri, Dec 19, 2008 at 3:10 AM, Vladimir Batov <batov_at_[hidden]> wrote:
>>> ... > 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.

I agree.  I like things to either default construct with a full usable
object, or to not be able to default construct it at all.