[boost] Re: Swapability of named objects?

From: Daniel Spangenberg (dsp_at_[hidden])
Date: 2003-11-06 02:44:51

David Abrahams schrieb:
[snip]

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

Thanks, Dave.
But honestly, after reading it, I don't see any fundamental contradiction to
my loose definition of swappable, especially, if you consider my previous
posting's paragraph concerning overloadability of swap.

Howard proposes that **one or more** of the following conditions apply:

a. T is swappable if T is copyconstructible and assignable.
-> This requires copyability and this is not what I am discussing about.
I spoke about "non-copy-swappability"

b. T is swappable if a namespace scope function named swap exists in
the same namespace as the definition of T, such that the expression swap(t, u)
is valid and has the semantics described in Table??.
-> This is the point I am discussing about! My first definition left the namespace

scope function swap out, because I was think of overloading std::swap. But if
you honestly read my last posting, you have to accept, that I effectively meant
the same thing, don't you?

> >> 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 didn't answer at this place, because the following stuff of my previous posting
extended my original definition, which was coloured by the non-overloading-issue
of std::swap.

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

OK, maybe incomplete, but this was not the place, to **completely** define
swappability. As I showed you above, Howard's proposal essentially contains
my swappability definition. At this place, the need for copyability and
assignability
was not under discussion (which we would need for fundamental types, of course).

The point under discussion was property b of his proposal.

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

You know very well, **why** I left out the valid expression. I explained it
as an deficiency in overloading std::swap, Howard solves it elegantly by
requiring a namespace scope swap and adding further requirements on several
algorithms of the standard library. So what problems are left now?

Now, finally: What about the swappability of named_object?

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

I think we have answered this question already, don't we?

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

So you don't think, that Howards proposal is fair enough?

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

Reply?

Daniel