Move Semantics for POD-ish types

Question

Is there any point implementing a move constructor and move assignment operator for a struct or class that contains only primitive types? For instance,

struct Foo
{
    float x;
    float y;
    float z;

    /// ... ctor, copy ctor, assignment overload, etc...


};

I can see that, if I had something more complex, like:

struct Bar
{
    float x,y,z;
    std::string Name;
};  

where I'd rather move Name than copy it, a move ctor would make sense. However, "moving" a float doesn't (semantically) make sense to me.

Thoughts?

Answer 1

Note that a fully conforming C++11/14 compiler (not current version of VS2013) should automatically generate move operations for your Bar struct:

struct Bar
{
    float x,y,z;
    std::string Name;
};

In general, you should write move operations explicitly only for direct resource managers, that act like "building blocks". When you assemble together building blocks in more complex classes, the compiler should automatically generate move operations (using member-wise moves).

Answer 2

Even if you have that std::string member, it doesn't make sense to implement a move constructor. The implicit move constructor will already move each of the members, which in the case of float will just copy it, and in the case of std::string will move it.

You should only really need to provide a move constructor when your class is doing some of its own memory management. That is, if you're allocating memory in the constructor, then you'll want to transfer the pointer to that allocated memory during a move. See the Rule of Five.

It's possible to avoid this situation entirely if you always rely on smart pointers to handle your allocated memory for you. See the Rule of Zero.