[boost] Re: move semantics

From: Andrea Torsello (torsello_at_[hidden])
Date: 2004-04-17 04:41:17

"Andrea Torsello" <torsello_at_[hidden]> ha scritto nel messaggio
news:c5pd6u$67m$1_at_sea.gmane.org...
>

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

I looked for the problem, I had something like this:

Template<class Tp>
class X
{
...

template<class T>
    X(T& rhs, typename enable_if_same<X const,T>::type = 0) ;

template<class T>
 X(X<T> const &x) ;
// if T is convertible to Tp, creates a new container with the converted
elements from x
...
};

This last converting constructor interfered with the other templated
constructor.
One solution could be to something like:

X(X<U> const&, typename enable_if_different<Tp,U>::type=0) ;

but I had the same problem with operator = and in there the arity cannot
change.
I could use the convertible return type

template<class U>
enable_if_different<Tp, U, X<Tp>&> operator = (X<U> const &);

where enable_if_different<Tp, U, X<Tp>&> converts to X<Tp>&, but then it
would interfere with template type deduction when passing the result to a
templated function.

All minor problems, I agree, but all problems that my proposal do not
exhibit.

>
> Right, didn't realize that you could use the same trick here, good stuff!

Actually I was wrong. I checked and I did try it early on, but had problems
with
operator = because of the fixed arity, but I must admit that I didn't think
about the
convertible return type.

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

Again, changing the arity is not an option when overloading an operator.

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

Sorry for being so blunt, but I haven't seen any criticism on the approach
itself.
You didn't appear even to take a look at it to see if there is something
good about
it, and just started defending your approach.
I Think it was absolutely unwarranted, I am certainly not attacking your
work,
quite the opposite, I believe it is stuff of pure genius. Quite simply,
while using your
move construct I came up with something useful I thought was worth sharing.

Best Regards
Andrea Torsello