What do we get for free?

I ended up having a few issues with my program in the last post, firstly to do with getting the basic function working. I expected the compiler to generate the move constructor for me and in fact If I had been more lax and not defined the copy constructor myself it would have actually done so.

from here 

Yes, they are, in §12.8.9:

If the definition of a class X does not explicitly declare a move constructor, one will be implicitly declared as defaulted if and only if

• X does not have a user-declared copy constructor,
• X does not have a user-declared copy assignment operator,
• X does not have a user-declared move assignment operator,
• X does not have a user-declared destructor, and
• the move constructor would not be implicitly defined as deleted.

and §12.8.10

The implicitly-declared move constructor for class X will have the form

X::X(X&&)

Similarly for the move assigment operator. However because of the nature of the program and my expectations to see less messages generated from the copy constructor I realised the issue and worked through what the problem was.

What happens to those objects?

The second thing that is now apparent comes from the last output of the program. In this output it appears that the initial object I created using the const char*  constructor (assigned id 0) is destroyed many times through the program run. It is of course the temporaries generated along the way that are being destroyed, and the meaningful object is actually being passed from scope to scope. But the issue then becomes what happens to those temporaries?

In my previous example the data is simple and no real side effects will be seen because I don’t explicitly do anything in the destructor. However what if there were some resource management in that class and the destructor invokes some clean up? If the objects are moved through a stack of calls, at each level there will be destructors invoked which would invoke those operations.

This line of questioning has highlighted the fact that I made a mistake in the implementation which I will now correct:

The problem lies with the move constructor above. Whilst I set up the new object from the old, I never explicitly clear the old object. Thats why we see object(0) being destroyed multiple times.

What we need to do here is actually deactivate the old object so that if it were handling resources of some kind, we effectively render it inert. Stack Overflow had a question that addresses the best way to implement the move constructor which I believe gives the best idiomatic way to approach this:

Notice the other issue with my earlier code, this explicitly calls std::move()  for each member.

The real change though is the setting of the members in the donor object so that its destruction is safe.

 Revisiting assignment – right or wrong?

My assignment operator  implementation was driven by my use of the copy and swap idiom to ensure exception safety. The problem(?) is that we want to do a move to avoid extra allocations, and swap will effectively do an extra construction to effect the swap

At least that is what I expected. It does a move construction , then move assigns the two objects into the correct position (vc11).  So my original move assignment operator

is probably good.  There is a lot of discussion on SO about this particular area but this answer provides an interesting take and the whole page is interesting in general. I need to think more about this because I am still not sure if what I did is an error or not.

 

 

 

N.B. there are mistakes in the code below which I discuss in the next post. The reason they exist is that this site is more like a journal and so is fairly raw in content since its intended audience is me.

I have been trying to understand how the new features of C++11 are going to affect the code that I write.  I have read anecdotal evidence that the new move/rvalue functionality would help in writing more natural code.

 This Article describes the new rvalue references in C++11.

The following is a program that I wrote to understand how the objects are copied through the function calls. It is a simplified example of how some production code I am working will behave. The following is a non POD class  that simulates the data object that will exist in the real system.

The code that follows uses the class Bar . Basically at the heart there is a  queue<Bar> which contains instances of the  class Bar . This is populated indirectly via 2 layers of function calls. I began using a naive approach of passing by value because it is the simplest implementation.

The above is called by the following main function

The output with the pass by value approach is below.

In all the original object is copied 5 times through the process. The first optimisation I would do is to pass by reference through to the push into the queue. This will remove copies (1) & (2) above but there will be a copy made when the object is pushed. So now we are moving objects into the queue fairly efficiently. The return route still makes 2 copies before the return.

Bar t = w.WFooFunc2();  in the main function should on the face of it should make another copy, however it doesn’t because of Return Value Optimisation (RVO) or elision. This process means that the compiler will omit a copy of the object when returning from a function by value. It may not be possible if the function has multiple return points, or can return one of several objects.

So at this point I am looking at introducing the new move features of c++11.

The Bar object is modified to include a move constructor – much like a copy constructor, and move assignment operator. These are implemented in a similar way to the copy and assignment operator but are more efficient as they do not construct the object fully, they move the contents of the source into the new object leaving the old object as a shell – easily destroyed.

Now we can see that simply adding these operators (actually just the move constructor) has made a further saving over the last version without any change in the code at all. The Temporary created in the return before is now a move operation.

The second copy above is made when the local is copied from the return value of  front() . The value is copied because a reference is returned and so the compiler cannot know what the expected lifetime of that object is. It cannot see that the next operation (the pop() ) will cause it to be destoyed.

We can make a further change which brings into play a new function from the standard lib which forces the comiler to do the move:

This then leaves us with :

Now we only make the copy when the object is pushed into the queue. So can I get rid of that as well? The answer is yes by adding a further call to  std::move() when I push the object passed by reference

It turns out that I have made a slight mistake in this code that could have a bad effect in production code. I had instinctively realised but couldn’t place what the issue was. I started to talk about this in the next article and thinking about the situation made it clear what the issue is.