Comments on: The ‘Move Constructor’ in Visual C++ 2010 http://www.nuonsoft.com/blog/2009/06/07/the-move-constructor-in-visual-c-2010/ Sharing my software development progress + other interesting things. Tue, 31 Jan 2012 17:12:28 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Marc Gregoire http://www.nuonsoft.com/blog/2009/06/07/the-move-constructor-in-visual-c-2010/comment-page-1/#comment-31731 Marc Gregoire Sun, 09 Oct 2011 07:54:04 +0000 http://www.nuonsoft.com/blog/?p=263#comment-31731 Yes, in that case the copy constructor will be called, because a named object (myobj) will never be bound to an rvalue reference. Yes, in that case the copy constructor will be called, because a named object (myobj) will never be bound to an rvalue reference.

]]> By: Andrii http://www.nuonsoft.com/blog/2009/06/07/the-move-constructor-in-visual-c-2010/comment-page-1/#comment-31699 Andrii Fri, 07 Oct 2011 15:40:45 +0000 http://www.nuonsoft.com/blog/?p=263#comment-31699 and if it will be // Now with move constructor vector vec3; for (int i=0; i<siObjectCount; ++i) { CSomeObjectWithMoveConstructor myobj(siBufferSize); vec3.push_back(myobj); } copy constructor will be called? and if it will be

// Now with move constructor
vector vec3;
for (int i=0; i<siObjectCount; ++i)
{
CSomeObjectWithMoveConstructor myobj(siBufferSize);
vec3.push_back(myobj);
}

copy constructor will be called?

]]> By: air2 http://www.nuonsoft.com/blog/2009/06/07/the-move-constructor-in-visual-c-2010/comment-page-1/#comment-29550 air2 Fri, 10 Jun 2011 11:58:52 +0000 http://www.nuonsoft.com/blog/?p=263#comment-29550 I agree with Marc, although it is only interesting for debugging, in release mode, modern compilers will remove the instructions anyway due to optimalisation, because the see that the variable is not read after setting them. So it will not have bad performance effects what so ever. Therefore I see it as good code practice. I agree with Marc, although it is only interesting for debugging, in release mode, modern compilers will remove the instructions anyway due to optimalisation, because the see that the variable is not read after setting them. So it will not have bad performance effects what so ever. Therefore I see it as good code practice.

]]> By: Marc Gregoire http://www.nuonsoft.com/blog/2009/06/07/the-move-constructor-in-visual-c-2010/comment-page-1/#comment-21611 Marc Gregoire Thu, 15 Jul 2010 08:51:07 +0000 http://www.nuonsoft.com/blog/?p=263#comment-21611 I don't agree. It's good practise to reset variables to safe values after doing something with them. For example, after deleting a pointer, it's good to put that pointer back to NULL, even if the object is in the process of dying. It can make debugging for example easier. I don’t agree. It’s good practise to reset variables to safe values after doing something with them.
For example, after deleting a pointer, it’s good to put that pointer back to NULL, even if the object is in the process of dying. It can make debugging for example easier.

]]> By: Julian http://www.nuonsoft.com/blog/2009/06/07/the-move-constructor-in-visual-c-2010/comment-page-1/#comment-21597 Julian Wed, 14 Jul 2010 23:17:55 +0000 http://www.nuonsoft.com/blog/?p=263#comment-21597 I think that objSource.m_iBufferSize = 0; is not required; it is axiomatic that the only thing left for objSource to do is to die quietly. Whilst it is not wrong it could engender a whole field of misunderstanding! I think that objSource.m_iBufferSize = 0;
is not required; it is axiomatic that the only thing left for objSource to do is to die quietly.

Whilst it is not wrong it could engender a whole field of misunderstanding!

]]>