Boost logo

Boost :

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
>> >
>> >
>> >
>> > ?
>> 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:

>> > 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
> 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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at