Correct use of `= delete` for methods in classes
Solution 1
In addition to Xeo's answer:
Yes, everything is correct. If you wanted you could eliminate all of the deleted members but the deleted copy constructor and deleted copy assignment and have the same effect:
struct Picture { // Also ok
// 'explicit': no accidental cast from string to Picture
explicit Picture(const string &filename) { /* load image from file */ }
// no copy
Picture(const Picture&) = delete;
// no assign
Picture& operator=(const Picture&) = delete;
};
The explicit declaration of the copy constructor inhibits the implicit generation of the default constructor, move constructor and move assignment members. Having these members explicitly deleted is a matter of taste. Some will probably see it as good documentation. Others may see it as overly verbose.
Solution 2
Seems fine to me. The return value of operator=
must be a normal reference, even if the object is constructed from a rvalue reference. That is because you can't just compile an lvalue (*this
) to an rvalue.
And it should take that rvalue reference per non-const Picture& operator=(Picture&&)
. How would you move from a constant object? ;)
towi
Programmer, Algorithmicist, Programming Languagcist, Pythonist, C++icist, Photographer, Boardgamer.
Updated on June 17, 2022Comments
-
towi almost 2 years
Is the following snipplet correct for un-defining all otherwise generated methods and constructors for a class?
struct Picture { // 'explicit': no accidental cast from string to Picture explicit Picture(const string &filename) { /* load image from file */ } // no accidental construction, i.e. temporaries and the like Picture() = delete; // no copy Picture(const Picture&) = delete; // no assign Picture& operator=(const Picture&) = delete; // no move Picture(Picture&&) = delete; // no move-assign Picture& operator=(Picture&&) = delete; // return type correct? };
This deletes every default compiler implementation and only leaves the destructor, right? Without it the class would be (almost) unusable I guess, but I could delete it as well, correct?
Is the return type
Picture&
of the move-assignoperator=(Picture&&)
correct? Does it make a difference if I wrotePicture&&
for the return type?