... > 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). Best, Vladimir.
On Fri, Dec 19, 2008 at 3:10 AM, Vladimir Batov <batov@people.net.au> 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.
On Fri, Dec 19, 2008 at 12:47, OvermindDL1 <overminddl1@gmail.com> wrote:
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 agree. I like things to either default construct with a full usable object, or to not be able to default construct it at all.
What defines "fully usable"? All the member functions in a nil UUID return reasonable, predictable results, and none throw exceptions. Do you have some examples of other objects that do (or should) behave similarly to your desire for uuid? In my view, a uuid is essentially a pointer (though the dereference operation is context-dependant), so it should be null/nil by default until you define what it should be pointing to. Take, for example, a map<string, uuid>. No default constructor means that you can't use operator[], and one that generates a random uuid means you lose the convenient semantics of a non-existant element being equivalent to the (trivially) invalid one. (I say "trivially" because afaik most uses of uuid do allow you to check whether a uuid points to something or if it's garbage, though not terribly quickly or conveniently.) I'm also not the only person that thinks default-constructed instances should be equal. Take something as reasonable as vector<uuid> v; v.resize(10); In C++03, that resize call was specified (through a default argument) to be equivalent to v.resize(10, uuid());. In C++0x (draft n2798), however, it's (presumably for optimization reasons) a separate overload from the 2-parameter version, and is specifed to, in this case, "append [10] default-constructed elements to the sequence". Given the apparent implemenation of that is to placement default-construct them, it'd give a different result from the C++03 version if uuid() returned something random. ~ Scott
participants (3)
-
OvermindDL1 -
Scott McMurray -
Vladimir Batov