[boost] Re: move semantics

From: Andrea Torsello (torsello_at_[hidden])
Date: 2004-04-16 14:32:44

"David Abrahams" <dave_at_[hidden]> writes:
> >>  I'm not sure what you mean, but AFAICT case #2 is handled just fine
> >> by conforming compilers.  Did you read
> >> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1610.html?
>
> So did you?

Yes.

> The comment was wrong; either behavior could be interpreted as correct
> if you stretch, but Comeau's is arguably too
> restrictive. Unfortunately there's no macro we can use to detect
> strict mode on EDG; it might mean that the implicit move optimization
> needs to be turned off for certain cases with those compilers.

Correct me if I am wrong, but if both behaviour could be interpreted as
correct
based on the current standard, it means that relying on one interpretation
is
undefine behaviour. At least untill a TC is issued.

Besides it is not the only problem. I didn't just start to create my own
version
for pleasure. I started using your approach but the templated constructor
had weird
interactions with other 2 parameter constructors. I cannot remember the case
off hand,
but I will look for it and post it.

> There is never a need to pass a temporary by const ref if you can
> move it.

What if the user of the library wants  to pass the object to a function
that has that signature? One of the main goal is for the move infrastructure
to be as
transparent as possible.

> Yes.
>
>       template <class T>
>       enable_if_same<T const, X const, void> f(T&); // lvalues
>
>       void f(move_from<X>);  // temporaries

Right, didn't realize that you could use the same trick here, good stuff!
Anyway, using enable_if_same as a result type convertible to the required
type might cause problem with template type deduction if the result is
passed to a templated function, while if it is used as a second paramater
with default value (as in the constructor) it changes the arity of the
function, which might cause problem with functional programming (this one is
probably not a real problem). Anyway forcing an otherwise non-templated
fiunction to be templated, while not a real problem is not really optimal,
especially considering the difficulty most compilers have with the export
keyword. Of corse, the templated class might just delegate all work to a non
templated class, but still.

> > The code snipped you sent on the quoted message doesn't appear to
> > allow it, but as I said, I am not sure about newer versions.
>
> Why don't you do some research?  It's all in the sandbox.

I did, and I proposed an alternative which has some advantages and some
disadvantages.
If you like i,t please use it, if you don't, don't! I was looking for
feedback and constructive criticism,
not forcing my approach to anyone.

> I still don't understand why you think it's important to distinguish
> const temporaries from const lvalues.

As you said in another post, it is not a problem to move from a const
temporary (the compiler might just copy the const temporary to a non const
temporary and optimize the copy away), hece you want to move from const
temporaries. On the other hand, you should certainly not move from lvalues.

Best regards
Andrea Torsello