In this article, I will try to explain move semantics in C++11 using a more pragmatic approach, by answering specific questions developers may ask. We’ll start with why moves are needed in the first place, then see how to use them, and eventually move onto common misconceptions and pitfalls.

The future is here! I recently got my hands on a pair of the awesome Oculus Rift VR goggles, and I am extremely excited. While the demo software is impressive out of the box, a lot of factors must come together to create a compelling experience. In this post I will discuss the mechanisms behind the sense of scale in VR, highlight its importance and propose new ways to explore this effect.

In Part 1, the “value of rvalues” was discussed, as well as their use in the context of std::async. A problem was observed with how lvalues are handled, so in this part I will introduce perfect forwarding to deal with rvalues and lvalues generically and try to provide an optimal approach in that context.

Perfect forwarding allows template functions to forward the arguments “as is” to any other function they call. This helps minimize the number of unnecessary copies and conversions when delegating information to other functions. In a quest to get rid of copying completely in a library I was writing, I came across the problem of perfect forwarding to functions launched on a separate thread.

Very rarely, a case comes up where a new function is required even if it is functionally identical to another one. In these cases another meaning is attached to these functions beyond their interface, and machine instructions; reusing it will actually be counterproductive. We examine such a case I encountered at my workplace.

When I first started working on a team using Qt (in a C++ environment), I would hear co-workers talk about “objects being on threads”, and then immediately talk about how several threads are accessing the same object. These two seemingly opposite ideas confused me at first. Let’s untagle the mystery!