Does an explicit move ctor eliminate implicit copy ctor?

Question

I read in the accepted answer here that:

[a] copy constructor and copy assignment operator won't be generated for a class that explicitly declares a move constructor or move assignment operator

I do notice (g++ 4.7.2) that if you define a move constructor, it will be used with, e.g., push_back(), whereas if all you do is = delete the copy constructor, you don't get an implicit move constructor -- you get an error. [...which leads me to wonder which one (move or copy) is actually used if you don't do anything explicitly...]

However, this online reference does not make the same explicit promises about the copy constructor not being implicitly defined when you define a move constructor.

So my question is, is the first quote guaranteed by the standard (including the "or")? I would prefer, with some classes which need an explicit destructor, to complete the "rule of five" with just a move constructor and a (deleted) move operator and rely on the implicit copy methods not being defined. If I can't rely on that, then I'll have to explicitly =delete them -- but that's a lot of potentially redundant stuff.

Answer 1

So my question is, is the first quote guaranteed by the standard (including the "or")?

Yes, your first quote is guaranted by the standard.

Quote from the standard (draft n3690):

12.8 Copying and moving class objects [class.copy]

7/ If the class definition does not explicitly declare a copy constructor, one is declared implicitly. If the class definition declares a move constructor or move assignment operator, the implicitly declared copy constructor is defined as deleted; otherwise, it is defined as defaulted (8.4). The latter case is deprecated if the class has a user-declared copy assignment operator or a user-declared destructor.