26


What would be the correct way to implement a move constructor considering the following class:

class C { public: C(); C(C&& c); private: std::string string; }

Of course, the idea is to avoid copying string or deallocating it twice.
Lets assume the basic example is just for clarity and I do need a move constructor.


I tried:

C::C(C&& c) { //move ctor string = std::move(c.string); }

And

C::C(C&& c) : string(std::move(c.string)) { //move ctor }

Both compile fine on gcc 4.8 and run fine. It seems option A is the correct behaviour, string gets copied instead of moved with option B.
Is this the correct implementation of a move constructor?

Improve this question
9
  • 4
    The correct implementation is just let the compiler generate it. class C { std::string string; }; Commented May 1, 2012 at 18:24
  • 2
    This is of course a simple example. I do need a move constructor. What do I do with the string in this case? Ignore it? Commented May 1, 2012 at 18:26
  • 2
    The first one constructs string, then moves. The second one is better. Also: don't name variables the same as a type. Option B should be moving the string. Commented May 1, 2012 at 18:30
  • 3
    @Fraser: (1) OP mentioned gcc 4.8, which does automatically generate move c'tors (even 4.7 does), and (2) that's VC11's bug. Commented May 1, 2012 at 18:34
  • 1
    @KennyTM I know gcc was mentioned, but it's probably not good advice at the moment to rely on compiler generated move constructors unless it's clear that only compliant compilers will be used. (Also, I wouldn't call this a bug so much as missing functionality) Commented May 1, 2012 at 18:39

4 Answers 4

Reset to default
15

Since std::string itself has a move-ctor, the implicitly defined move-ctor for C will take care of the proper move operation. You may not define it yourself. However, if you have any other data member and specifically:

12.8 Copying and moving class objects

12 An implicitly-declared copy/move constructor is an inline public member of its class. A defaulted copy- /move constructor for a class X is defined as deleted (8.4.3) if X has:

— a variant member with a non-trivial corresponding constructor and X is a union-like class,

— a non-static data member of class type M (or array thereof) that cannot be copied/moved because overload resolution (13.3), as applied to M’s corresponding constructor, results in an ambiguity or a function that is deleted or inaccessible from the defaulted constructor, or

— a direct or virtual base class B that cannot be copied/moved because overload resolution (13.3), as applied to B’s corresponding constructor, results in an ambiguity or a function that is deleted or inaccessible from the defaulted constructor, or

— for the move constructor, a non-static data member or direct or virtual base class with a type that does not have a move constructor and is not trivially copyable.

13 A copy/move constructor for class X is trivial if it is neither user-provided nor deleted and if

— class X has no virtual functions (10.3) and no virtual base classes (10.1), and functions (10.3) and no virtual base classes (10.1), and

— the constructor selected to copy/move each direct base class subobject is trivial, and

— for each non-static data member of X that is of class type (or array thereof), the constructor selected to copy/move that member is trivial; otherwise the copy/move constructor is non-trivial.

you may want to implement your own move-ctor.

In case you need the move-ctor, prefer the initializer list syntax. Always! Otherwise, you may end up with a default construction per object not mentioned in the initializer list (which is what you're forced for member objects with non-default ctors only).

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

11

Both your variants will move the string. The second variant should be preferred because it will not default construct an empty string just to move assign it afterwards.

Check your testcase and then your compiler's bugzilla list. You need to trace calls to both string::operator=(string&&) (1st case) and string::string(string&&) (2nd case) if you want to ensure for both cases that they move.

Improve this answer

1 Comment

That is what I did. In second case no move operator/constructors are called.
3

Both Constructors should work. So both are correct move constructors. The second one might be more efficient, since the first one default constructs string only to assign to it, while the second will simply move construct it and should therefore be more efficient. If the second one is less efficient I would suspect a compiler bug (remember that C++11 support is still not complete for current compilers) or a flawed test methology (how exactly do you test copy vs move and are you sure the move constructor not the assignment op is called in both cases?).

Of course whenever possibly you could simply let the compiler generate your constructor via C(C&&) = default;.

Improve this answer

Comments

2

There is no need to implement a move constructor here since you don't have to manually manage memory. Move constructors are only useful when you manually use dynamic arrays in your class.

You can still explicitly have the compiler create the default move constructor even though it should have already been done even if you don't request it:

C(C&& c) = default;
Improve this answer

1 Comment

I find mocha constructors useful.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.