Hello,

I read the N3035 and have a question.
N3035 says that the move ctors on a tuple move each element of the
source tuple
to the corresponding elements of the target tuple to be constructed,
e.g. 20.4.2.1/16.

I'm afraid this specification is quite dangerous in the case
where the source tuple has an lvalue-reference element type.

Consider that one innocently constructs a tuple
with an lvalue-reference which referes to an object he/she owns.
If that tuple is moved anywhere (by returning from or throwing away to
a function),
the object can be silently moved to another object by a tuple move
ctor,
of which he/she never dreamed.

Please correct me if I'm wrong about the interpretation of the
specification,
but I would be grateful if you could tell me a little about your
views.

Thank you very much in advance.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 20 Mrz., 21:35, Ai Azuma <ai.az...@gmail.com> wrote:
> I read the N3035 and have a question.
> N3035 says that the move ctors on a tuple move each element of the
> source tuple
> to the corresponding elements of the target tuple to be constructed,
> e.g. 20.4.2.1/16.
>
> I'm afraid this specification is quite dangerous in the case
> where the source tuple has an lvalue-reference element type.
>
> Consider that one innocently constructs a tuple
> with an lvalue-reference which referes to an object he/she owns.
> If that tuple is moved anywhere (by returning from or throwing away to
> a function),
> the object can be silently moved to another object by a tuple move
> ctor,
> of which he/she never dreamed.
>
> Please correct me if I'm wrong about the interpretation of the
> specification,
> but I would be grateful if you could tell me a little about your
> views.

The current description of the semantics of the move constructor
of both pair and tuple is defective. In fact, any initialization of
an lvalue-reference with std::move(something) will be ill-formed
anyway, because the lvalue-reference won't bind to the rvalue
(more precisely: The xvalue according to the new expression
value taxonomy). The correct solution is to call
forward<Ti>(get<i>(u)) for the i-th element, it ensures that an
lvalue reference is bound to an lvalue, but not to an rvalue.

An issue (LWG 1326) has recently been created to care
about that problem. Just observe

http://www.open-std.org/jtc1/sc22/wg21/

for the updated issue list.

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]