[boost] Re: Swapability of named objects?

From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-11-05 04:19:08

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?).

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

> > But I see no connection to my point, which is obviously related to
> > my missing definition of Swappable. This terminus cannot be found
> ???----------------------------------------^^^^^^^^

Sorry, this must be a Germanism. I meant "term" or "concept". After asking
LEO I can understand your question marks... ;-))

> > in C++98, nor could I find any definition on the pages of the commitee.
> >
> > 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?
>
> > 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
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.

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?

The definition of copyability also bases on a member function,
with the (important) difference, that it is part of the language, not
of the library. So I can legaly define it

- by an phenomenological description, as above, which is mostly
useless because inprecise
- based on library functions, e.g. swap, or member functions, e.g.
swap

The second way is not necessarily bad, because many library
concept base on name concepts (most template programming
needs this) otherwise we wounld't have name conventions like
push_back or similar, which are connected to some conventions
in their meaning.

Ideally I would base my definition on the free std::swap function,
**provided** I can legally overload it.

If this finally does not satisfy you: What is *your* definition of
swappability and how does it's definition relate to boost::scoped_ptr,
which I would in fact describe as "swappable but not copyable"?

Greetings from Bremen,

Daniel