unique_ptr assignment
restor
I noticed this strange signature of the unique_ptr's assignment in
N3000:
template <class T, class D = default_delete<T>>
class unique_ptr {
...
template <class U, class E> unique_ptr& operator=(unique_ptr<U,
E>&& u);
...
}
First, it is not obvious that an assignment (of any type whatsoever)
should return a value. It could be void for every assignment, and the
assignment would still be useful, and hardly any would tell the
difference. But since an assignment does return an l-value, I always
thought it is to make the following two lines:
p = q;
f(p);
shrink to:
f(p = q);
The semantics are obvious if p and q are of the same type, but here,
for the unique_ptr they are not:
p points to T, but (p = q) points to U. This means that when choosing
which function f to choose from the overload candidates, the function f
(p) may be different than the function f(p = q).
Is this return operator= return type a bug, or is there any practical
problem that is solved by this design?
Regards,
&rzej
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
SG
> Hi,
> I noticed this strange signature of the unique_ptr's assignment in
> N3000:
>
> template <class T, class D = default_delete<T>>
> class unique_ptr {
> ...
> template <class U, class E>
> unique_ptr& operator=(unique_ptr<U, E>&& u);
unique_ptr<T,D>
> ...
> }
[snip]
> [...We expect...]
> p = q;
> f(p);
> [...to be equivalent to...]
> f(p = q);
>
> The semantics are obvious if p and q are of the same type, but here,
> for the unique_ptr they are not:
But they are!
> p points to T, but (p = q) points to U.
No, it doesn't. You got confused with the "template<...>" part in
front of the return type. The return type is unique_ptr<T,D>&.
> Is this return operator= return type a bug, or is there any practical
> problem that is solved by this design?
Neither.
Cheers,
SG
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
Sean Hunt
> The semantics are obvious if p and q are of the same type, but here,
> for the unique_ptr they are not:
> which function f to choose from the overload candidates, the function f
> (p) may be different than the function f(p = q).
>
> problem that is solved by this design?
Nope, read the signature more closely. The return type is unadorned
`unique_ptr&`, which means it's the same type as the template itself,
which is `unique_ptr<T>&`. The `T` is the `T` for the `unique_ptr`
object on the left-hand side of the assignment, so `p = q; f(p)` and `f
(p = q)` will do the same thing.
Sean
restor
> On Dec 17, 11:00 am, restor <akrze...@gmail.com> wrote:
>
> > The semantics are obvious if p and q are of the same type, but here,
> > for the unique_ptr they are not:
> > p points to T, but (p = q) points to U. This means that when choosing
> > which function f to choose from the overload candidates, the function f
> > (p) may be different than the function f(p = q).
>
> > Is this return operator= return type a bug, or is there any practical
> > problem that is solved by this design?
>
> Nope, read the signature more closely. The return type is unadorned
> `unique_ptr&`, which means it's the same type as the template itself,
> which is `unique_ptr<T>&`. The `T` is the `T` for the `unique_ptr`
> object on the left-hand side of the assignment, so `p = q; f(p)` and `f
> (p = q)` will do the same thing.
>
> Sean
You're right. I mis-read the declaration. 6 years of studying C++ and
I still cannot parse a simple template declaration.
Thanks,
&rzej
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]