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
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk