Subject: Re: [boost] [uuid] Interface
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-20 21:22:08
> What makes the Nil UUID not "valid"?
Scott, I suspect you are asking the questions you already know the answers
to. Still I'll try answering them. Nil is invalid in the same way as NULL is
invalid -- it does not deliver the main properties the class has been
designed for. nil and NULL are specifically introduced to be different and
distinguishable from normal "valid" objects. *That* makes them "invalid".
> It has its own section in the
> RFC, and regardless of what the default constructor does, there's
> going to be uuids::nil() to get an instance of it.
Yes, I hope there will "be uuids::nil() to get an instance of it" and I'd
like that to be the only get-nil mechanism. I thought the original
discussion centered around the default constructor behavior and to me that
behavior is very important what the default constructor does.
> If it's "invalid", why is it still available?
It is available for the same reason NULL and -1 (for many C functions) (and
many other objects designated as "invalid") are available and I really do
not want to be elaborating obvoius things of that kind. Still, it does not
make uuid::nill() or uuid a pointer.
>>> Do you have some examples of other objects that do (or should) behave
>>> similarly to your desire for uuid?
>> int example = int();
>> double d = double();
>> std::string str;
>> in fact probably all the classes with the value semantics.
> None of those do any generation of any sort;
To me it is application-specific what any constructor does or does not,
generation or no generation.
> They all have T() == T();
So what? The fact that for some classes T() == T() is purely coincidental.
Or is it in the Standard? I'll promptly agree/surrender if it is a Standard
> And they all are rarely useful as-is.
An 0 integer and an empty string "are rarely useful as-is"? I do not
understand what you mean.
> I'd argue that pointers do have value semantics.
I am not sure what to say to that.
> swap(int *, int *) can only swap the pointees, not the pointers
In fact, swap(int* p1, int* p2) swaps the *pointers* because after the call
p1 will have the value of p2 and p2 will have the value of p1.
> I'd say that the fundamental property of pointers is that, in the
> relevant domain, there exists an injective map from set the "pointees"
> to the set of pointers (the "address of" operator, for plain pointers)
> and a surjective map from the set of pointer to the set of "pointees"
> (the "dereference" operator, for plain pointer).
> UUIDs fit that definition. If you label each, say, database record
> with a UUID, there's a surjective map from the UUID to the record
> (with something like "SELECT ... WHERE id = @id" in SQL), and an
> injective map from the record to the UUID (by looking at the id field
> in the record).
The same concept is likely to have different meanings in different areas and
on different absraction levels. My interpretation of a pointer is pretty
much as Wikipedia desribes it: In computer science, a pointer is a
programming language data type whose value refers directly to (or "points
to") another value stored elsewhere... For me UUID does not fit *that*
> The point is that this is a *breaking* change in the standard unless
> you assume that value_type() == value_type() for every type that could
> be put in a std::vector in C++03. I can't think of any applicable type
> that breaks that assumption -- and presumably the committee couldn't
> either -- so I don't think that making UUID break it is a good idea.
I'd appreciate if you could clarify the following for me: Is value_type() ==
value_type() an assumpton you made, or is it an assumption you know the
committee made or the committee stated somewhere that was an expectation or
even a requirement for not following which would be a *breaking* change?
Could you please indicate any documents or parts of the Standard (I could
not find anything of that kind)? And what exactly "my-style" UUID is
breaking? These are honest questions. We've been using "my-style" UUID quite
extensively (over a year) in our project and would like to know what exactly
we are breaking.
Apologies that I snipped and left unanswered quite a bit of your replies.
They seem to cover too many different areas/issues and I simply have no
capacity to agrue of such a wide front. So, I am happy you have it your way.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk