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.