[boost] Re: Swapability of named objects?

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-05 12:19:40

Daniel Spangenberg <dsp_at_[hidden]> writes:

> David Abrahams schrieb:
>
>> Daniel Spangenberg <dsp_at_[hidden]> writes:
>>
>> > David Abrahams schrieb:
>> >
>> >> Daniel Spangenberg <dsp_at_[hidden]> writes:
>> >>
>> >> You'd better supply a careful definition of Swappable before I
>> >> believe that.  Once Howard Hinnant's LWG issue 301 changes are
>> >> accepted, the picture may look a bit different.
>> >
>> > Hmmh, I cannot relate LWG issue 301 to this point of question or even
>> > Howard Hinnant related to this ;-)
>> >
>> > Maybe you mean your **own** issue 227
>> >
>> > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#227
>> >
>> > ?
>>
>> Nope.
>
> These telegram style answers are neither very typical for you nor does it
> help very much in this situation (I remember, that you sometimes grumble
> about one multi threading expert who has his own style of explanation,
> strongly based on quotes, why don't you do better?).

Because I really, honestly thought it was 301.  Sorry.

> Could you please explain, **which** issue you meant, obviously it can't be
> 301.

The paper I'm referring to is actually:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1523.htm

>> > OK, I mean by swappable that this type provides a swap member
>> > function.
>>
>> Oh!  That's the last thing I expected!  So ints are not Swappable.
>> Now, are there any restrictions on the signature of that function or
>> its semantics?

No reply?

>> > I do not see any connection between swapable and copyable.
>>
>> Given *your* (partial) definition of Swappable there is no connection.
>> I don't happen to think it's a very useful definition, though.
>
> You are right, but the main reason for my previously given very
> specialized

...and incomplete...

> definition on swappable is, that it does **not** depend on
> std::swap. You have given some good reasoning on your own about some
> useless aspects of std::swap - I mean the points concerning the
> legality of overloading it, see
>
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#226
>
> I will generalize and precise my definition here:
>
> Swappability is the ability of an instance of a given type to exchange its
> contents (data members for UD types) representing (characterizing?) its
> **individual** state with another instance of the same type.
> The individual state is anything what is not a class specific state (mostly
> represented by static data members).
>
> This forbids e.g.
>
> struct A
> {
>   const int c_;
>   A(int val) : c_(val) {}
> };
>
> but allows
>
> struct B
> {
>   static const int cc_ = 123;
> };
>
> or any fundamental type.

IMO that's overconstrained.  Even if you consider swapping two B's
what difference does it make that b1.cc_ is exchanged with b2.cc_?

You're still missing a function signature or at least a list of valid
expressions.

> The disadvantage of this very general definition is, that we see no
> direct connection to member functions, like swap.
>
> You say, that you think that my originally proposed specialized
> definition of swappability is not very useful, but I ask you: why?

Because you can't use it on lots of objects (like ints) which can
certainly be swapped.

> If this finally does not satisfy you: What is *your* definition of
> swappability 

I don't have one; *you're* the one using the term.

> and how does it's definition relate to boost::scoped_ptr, which I
> would in fact describe as "swappable but not copyable"?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com