C++ Performance – Writing Code That Relies on Compiler Optimizations

Also, though good compilers won't set aside storage for const objects of integer types...

A slightly more correct statement would be that compilers wouldn't set aside data memory for const objects of integer type: they would trade it for program memory. There is no difference between the two under Von Neumann architecture, but in other architectures, such as Harvard, the distinction is rather important.

To fully understand what's going on, you need to recall how assembly language loads data for processing. There are two fundamental ways to load the data - read a memory from a specific location (so called direct addressing mode), or set a constant specified as part of the instruction itself (so called immediate addressing mode). When compiler sees a const int x = 5 declaration followed by int a = x+x, it has two options:

• Put 5 in a data memory, as if it were a variable, and generate direct load instructions; treat writes to x as errors
• Each time the x is referenced, generate an immediate load instruction of the value 5

In the first case you will see a read from x into the accumulator register, an addition of the value at the location of x to accumulator, and a store into the location of a. In the second case you will see a load immediate of five, an add immediate of five, followed by a store into the location of a. Some compilers may figure out that you are adding a constant to itself, optimize a = x+x into a = 10, and generate a single instruction that stores ten at the location of a.

Move semantics introduce a whole dimension to C++ - it isn't just there to let you return values cheaply.

For example, without move-semantics std::unique_ptr doesn't work - look at std::auto_ptr, which was deprecated with the introduction of move-semantics and removed in C++17. Moving a resource is vastly different from copying it. It allows transfer of ownership of a unique item.

For example, let's not look at std::unique_ptr, since it is fairly well discussed. Let's look at, say, a Vertex Buffer Object in OpenGL. A vertex buffer represents memory on the GPU - it needs to be allocated and deallocated using special functions, possibly having tight constraints on how long it can live. It is also important that only one owner use it.

class vertex_buffer_object
{
    vertex_buffer_object(size_t size)
    {
        this->vbo_handle = create_buffer(..., size);
    }

    ~vertex_buffer_object()
    {
        release_buffer(vbo_handle);
    }
};

void create_and_use()
{
    vertex_buffer_object vbo = vertex_buffer_object(SIZE);

    do_init(vbo); //send reference, do not transfer ownership

    renderer.add(std::move(vbo)); //transfer ownership to renderer
}

Now, this could be done with a std::shared_ptr - but this resource is not to be shared. This makes it confusing to use a shared pointer. You could use std::unique_ptr, but that still requires move semantics.

Obviously, I haven't implemented a move constructor, but you get the idea.

The relevant thing here is that some resources aren't copyable. You can pass around pointers instead of moving, but unless you use unique_ptr, there is the issue of ownership. It is worthwhile to be as clear as possible as to what the intent of the code is, so a move-constructor is probably the best approach.