Understanding the move instructor (c++11)

Started by
3 comments, last by swiftcoder 7 years, 5 months ago

Hi all,

I'm trying to understand how the new (C++11) move constructor and move assignment works in classes.

Initially I thought I could test by simply having a 1 on 1 relation between a specific creation/ assignment of the class, which would call one of the 4 member functions:

- copy constructor

- move constructor

- copy assignment

- move assignment

The code/ test below works, but for example when I comment out just the "copy constructor", both nextPack(firstPack) and std::move(nextPack) are no longer allowed (deleted). I would think that the 2nd one (std::move(nextPack)) would be allowed, because I didn't explicitly call delete/ specify the move constructor. Other combinations (just specify 1 of the 4 in the class definition, leads to 2 of the 4 situations not being allowed, instead of 1).

I hope someone can shed some light on this.


// CLASS DEFINITION

	CD3dShaderPack(const CD3dShaderPack& other) = delete;				// copy constructor
//	CD3dShaderPack(CD3dShaderPack&& other) = delete;					// move constructor

//	CD3dShaderPack& operator=(const CD3dShaderPack& other) = delete;	// copy assignment
//	CD3dShaderPack& operator=(CD3dShaderPack&& other) = delete;			// move assignment

// TEST CASES

	Crealysm::D3DRENDERER::CD3dShaderPack firstPack;
	Crealysm::D3DRENDERER::CD3dShaderPack nextPack(firstPack);				// copy constructor

	nextPack = firstPack;													// copy assignment
	nextPack = std::move(firstPack);										// move assignment

	Crealysm::D3DRENDERER::CD3dShaderPack thirdPack(std::move(nextPack));	// move constructor


Crealysm game & engine development: http://www.crealysm.com

Looking for a passionate, disciplined and structured producer? PM me

Advertisement

Many things cause the compiler to implicitly delete constructors; the move constructor is particularly sensitive to implicit deletion. See here, the section on implicit deletion.

My suggestion to you in chat to explicitly delete them is because I feel that it's better, at this point in your understanding of the subject, to be explicit about it.

Thanks, perhaps when I get more experienced on them, I'll be able to 'update' the code and remove 1 or 2 of the 4 that are now explicit.

For understanding the, current solution works fine, because I now know 100% sure that none of the 4 options will accidentally work.

I've read the URL/ link above, when I get the hang of it (or check all conditions) I could decide for each class:

- do nothing, move is fine (implicitly, no static members etc.)

- explicitly create the move constructor/ assignment myself

- explicitly define as 'deleted' (like I did with the ShaderPack class)

The same goes for copy constructor/ assignment I guess.

Crealysm game & engine development: http://www.crealysm.com

Looking for a passionate, disciplined and structured producer? PM me

Pete Isensee gave a great talk on this topic:

http://www.tantalon.com/pete/files/gdc12_faster_cpp.zip

Thanks, perhaps when I get more experienced on them, I'll be able to 'update' the code and remove 1 or 2 of the 4 that are now explicit.

I'm not aware of any reason to prefer implicit deletion over explicit.

Relying excessively on implicit behaviour tends to be a sign of someone trying to write "clever" code, and at some point, either your coworkers, or you when you try and read this code again in a year, will be glad that you made it explicit.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

This topic is closed to new replies.

Advertisement