I realized that the common-knowledge that "you cannot move a const object" is not entirely true. You can, if you declare the move ctor as
X(const X&&);
Full example below:
#include <iostream>
struct X
{
X() = default;
X(const X&&) {std::cout << "const move\n";}
};
int main()
{
const X x{};
X y{std::move(x)};
}
Question: is there any reason why one would want such a thing? Any useful/practical scenario?
Your example doesn't move anything. Yes, you wrote std::move to get an rvalue and you invoked a move constructor, but nothing actually ends up getting moved. And it can't, because the object is const.
Unless the members you were interested in were marked mutable, you would not be able to do any "moving". So, there is no useful or even possible scenario.
Not sure whether it's practical, but it can be made legal provided the modified data members are mutable.
This program is legal, and if you like that kind of thing, would easily become hard to follow:
#include <iostream>
#include <string>
struct animal
{
animal(const animal&& other) : type(other.type) {
other.type = "dog";
}
animal() = default;
mutable std::string type = "cat";
};
std::ostream& operator<<(std::ostream& os, const animal& a)
{
return os << "I am a " << a.type;
}
std::ostream& operator<<(std::ostream& os, const animal&& a)
{
return os << "I am a " << a.type << " and I feel moved";
}
int main()
{
const auto cat = animal();
std::cout << cat << std::endl;
auto dog = std::move(cat);
std::cout << cat << std::endl;
std::cout << dog << std::endl;
std::cout << std::move(dog) << std::endl;
}
expected output:
I am a cat
I am a dog
I am a cat
I am a cat and I feel moved
As the comments have noted, you cannot actually "move" anything out of the argument object, because it is const (at least, not without a const cast, which is a bad idea as it could lead to UB). So it's clearly not useful for the sake of moving. The entire purpose of move semantics is to provide a performance optimization, and that is not happening here, so why do it?
That said, I can only think of two cases where this is useful. The first involves "greedy" constructors:
#include <iostream>
struct Foo {
Foo() = default;
Foo(const Foo&) { std::cerr << "copy constructor"; }
Foo(Foo&&) { std::cerr << "copy constructor"; }
template <class T>
Foo(T&&) { std::cerr << "forward"; }
};
const Foo bar() { return Foo{}; }
int main() {
Foo f2(bar());
return 0;
}
This program prints "forward". The reason why is because the deduced type in the template will be const Foo, making it a better match. This also shows up when you have perfect forwarding variadic constructors. Common for proxy objects. Of course returning by const value is bad practice, but strictly speaking it's not incorrect, and this may break your class. So you should really provide a Foo(const Foo&&) overload (which just delegates to the copy constructor); think of it as crossing a t or dotting an i when you are writing high quality generic code.
The second case occurs when you want to explicitly delete move constructors, or a move conversion operator:
struct Baz {
Baz() = default;
Baz(const Baz&) = default;
Baz(Baz&&) = delete;
};
const Baz zwug() { return {}; }
int main() {
Baz b2(zwug());
}
This program compiles so the author failed at their mission. The reason why is because const ref overloads match against const rvalues, and const rvalue construction was not explicitly deleted. If you want to delete moves you'll need to delete the const rvalue overload too.
The second example may seem wildly obscure but say you are writing a class that provides a view of a string. You may not want to allow it to be constructed from a string temporary, since you are at greater risk of the view being corrupted.
