Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>does <code>std::is_move_constructible&lt;T&gt;::value == true</code> implies that <code>T</code> has a usable move constructor?</p> </blockquote> <p>Either a move constructor or a copy constructor. Remember that the operation of copy construction satisfies all the requirements that are placed upon the operation move construction, and some more. </p> <p>In Standard terms, a <code>MoveConstructible</code> object is one for which the evaluation of the expression:</p> <pre><code>T u = rv; </code></pre> <p>makes <code>u</code> equivalent to the value of <code>rv</code> before the construction; the state of <code>rv</code> <em>after</em> being moved-from is <em>unspecified</em>. But since it is unspecified, this means the state could even be identical to the one <code>rv</code> had <em>before</em> being moved from: In other words, <code>u</code> could be a <em>copy</em> of <code>rv</code>.</p> <p>In fact, the Standard defines the <code>CopyConstructible</code> concept to be a <em>refinement</em> of the <code>MoveConstructible</code> concept (so everything which is <code>CopyConstructible</code> is also <code>MoveConstructible</code>, but not vice versa).</p> <blockquote> <p>if so, what is the default behaviour of it?</p> </blockquote> <p>The behavior of an implicitly generated move constructor is to perform a member-wise move of the data members of the type for which it is generated.</p> <p>Per Parahgraph 12.8/15 of the C++11 Standard:</p> <blockquote> <p>The implicitly-defined copy/move constructor for a non-union class <code>X</code> performs a <strong>memberwise copy/move of its bases and members</strong>. [ Note: <em>brace-or-equal-initializers</em> of non-static data members are ignored. See also the example in 12.6.2. —end note ]</p> </blockquote> <p>Moreover:</p> <blockquote> <p>1 - is <code>f2</code> move constructed ?</p> </blockquote> <p>Yes.</p> <blockquote> <p>2 - if so, shouldn't the rvalue be invalidated?</p> </blockquote> <p>Moving a <em>pointer</em> is the same as copying it. So no invalidation is going on, neither should it be going on. If you want a move constructor that leaves the moved-from object in a particular state (i.e. sets a pointer data member to <code>nullptr</code>), you have to write your own - or delegate this responsibility to some smart pointer class such as <code>std::unique_ptr</code>.</p> <p>Notice, that the word "<em>invalidated</em>" is not quite correct here. Move constructors (as well as move assignment operators) are meant to leave the moved-from object in a <em>valid</em> (yet unspecified) state. </p> <p>In other words, the class invariant needs to be respected - and it should be possible to invoke on a moved-from objects operations that do not have any precondition on its state (usually, destruction and assignment).</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload