Re: Implicit move constructor rules in c++0x still badly broken?

From:

Dragan Milenkovic <dragan@plusplus.rs>

Newsgroups:

comp.lang.c++.moderated

Date:

Tue, 15 Feb 2011 07:56:12 CST

Message-ID:

<ijdpak$l2s$1@speranza.aioe.org>

On 02/15/2011 11:38 AM, Patrik Kahari wrote:

I appreciate the example. But I'm not 100%

convinced that this is an actual problem in "real code".

[snip]

A proposed fixed sequence would be
1. a and b are constructed
2. xa an xb are constructed
3. xa and xb are destructed (invariant check succeeds on a and b)
4.1. a or b is moved (destroying the invariant, but this is fine as no
local object can depend on our invariants at this point. Call them 'a
or 'b)
4.2. a' and b' are destructed (fine)

Here 4.1 and 4.2 belong together as one unit. The move and destructor
represent a two step destruction. So a move is really half a
destructor. And the first half of the destructor was executed before
its time. First in, and last out should applies like usual.

I'm not sure which sequence is actually specified in c++0x. But I
think it should be the second one. Anyone see any problem with this?

I can think of one example... when we intentionally want to move
(not sure if this is a real-world example, though):

   Y move_out() {
     std::unique_lock<std::mutex> l(m_mutex);

     return std::move(m_y);
   }

// if m_mutex unlocks before the actual move, there would be
a race condition.

It also makes return kind of special. What if there was:

   void f(Y & res, bool choose) {
     Y a, b;
     InvariantChecker xa(a), xb(b);

     res = choose ? a : b;
   }

IMHO, this one should behave in the same way as return,
but under your proposed sequence, they do not.

--
Dragan

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]