Re: [boost] [uuid] Interface

Subject: Re: [boost] [uuid] Interface
From: Vladimir Batov (batov_at_[hidden])
Date: 2008-12-21 00:38:07

> A function with signature (int *, int *) -- the only way to pass a
> pointer to a function -- cannot swap the pointers, only the pointees.
> To swap the pointers themselves requires a function with signature
> (int *&, int*&), which is passing references-to-pointers, not
> pointers.
>
> So I consider pointers to have value semantics, and their pointees to
> have a kind of reference semantics.

Yes, it is understood that in that context (or on that level) pointers do 
have value semantics and they are copied as, say, integers, etc. etc. 
Although I think it was not exactly the context in which I was discussing 
value/pointer behavior differences.

...

>> I'd appreciate if you could clarify the following for me: Is value_type() 
>> ==
>> value_type() an assumption you made, ...
>
> I consider it an implied assumption by the committee, though it's not
> an explicit requirement of any sort.  This is based on the following 4
> statements, which I consider true:
>
> 1) The committee does not like to have the semantics of well-formed
> programs in one revision of the standard have different semantics in a
> later revision, and as such will only make such changes if they are
> unavoidable or, possibly, if they are determined to not affect any
> cases of consequence.
>
> 2) In C++03, resize(sz) on a vector is defined (through a default
> argument) to be equivalent to resize(sz, value_type())
> [vector.capacity], so any added elements are copy-constructed from the
> single default-constructed instance, so they are all equivalent (by
> container element requirement on the copy constructor).
>
> 3) In n2798, the C++0x draft from the 2008-10 mailing (as well as in
> previous drafts n2723 and n2588), there are 1- and 2-parameter
> overloads for resize on a vector [vector.capacity], and resize(sz) is
> defined, in the case where sz > size(), to "[append] sz - size()
> default constructed elements to the sequence".
>
> 4) If two default-constructed instances are not equivalent, then the
> change to [vector.capacity] changes the semantics of a well-formed
> program.
>
> Since this change was made to the standard and it's a relatively minor
> one, my impression is that the committee believes that any value_type
> where default-constructed instances are not equivalent is not a case
> of any consequence.
>
> But there are, as you mention, basically no requirements placed on
> default constructors for container element types, so my conclusion
> hangs on the strictness of application of statement 1 by the library
> working group.

Thank you for your thorough explanations. Much and truly appreciated. In 
fact, I feel much better as I was worrird that there was something lurking 
in our usage of UUID (with "my" default-constructor behavior). I really like 
your attidude towards the Standard but I hate to say that your 
interpretation of it left me unconvinced. I searched high and low and I was 
not able to find any hints about equivalency of the default-constructed 
objects (required, expected, assumed or otherwise). And I am still under 
impression that that requirement (or expectation) cannot be real as many 
classes are not even meant to be comparable. I do not think it makes them 
unusable with the std containers or breaking anything or second-class 
classes of no interest to the Standards committee.

Best,
V.