This library now contains a stub move implementation:
|
// Stubb out move for compatibility |
|
template<class T> |
|
T& move(T& t) noexcept { |
|
return t; |
|
} |
However, the implementation is incorrect: It simply returns the passed reference unmodified, but should convert it to a rvalue reference, see https://en.cppreference.com/w/cpp/utility/move
It seems this change originated at mike-matera/ArduinoSTL#36, which argues that the AVR compiler does not support move semantics, which is untrue. The compiler itself is just plain gcc, and when enabled with the right -std option, supports all language features of whatever standard used, including rvalue references (&& types). The only bit missing is libstdc++, which for move semantics mostly just means supporting std::move with a proper signature.
With the current std::move signature, this means that implementations that intend to use move semantics for a value will end up making needless copies instead.
A fix for this would be fairly simple, though looking at the docs at https://en.cppreference.com/w/cpp/utility/move would also require adding std::remove_reference.
More generally, though, I wonder if it would not be better to just omit the move function entirely. It is a C++11 feature, and this library mostly implements C++03. Mixing and matching versions like this makes it harder to use other libraries (like https://github.com/hideakitai/ArxTypeTraits) to add the C++11 and newer bits on top of the C++03 bits provided by this library...
This library now contains a stub move implementation:
Arduino_AVRSTL/src/utility
Lines 83 to 87 in b0f7e7d
However, the implementation is incorrect: It simply returns the passed reference unmodified, but should convert it to a rvalue reference, see https://en.cppreference.com/w/cpp/utility/move
It seems this change originated at mike-matera/ArduinoSTL#36, which argues that the AVR compiler does not support move semantics, which is untrue. The compiler itself is just plain gcc, and when enabled with the right
-stdoption, supports all language features of whatever standard used, including rvalue references (&&types). The only bit missing is libstdc++, which for move semantics mostly just means supportingstd::movewith a proper signature.With the current
std::movesignature, this means that implementations that intend to use move semantics for a value will end up making needless copies instead.A fix for this would be fairly simple, though looking at the docs at https://en.cppreference.com/w/cpp/utility/move would also require adding
std::remove_reference.More generally, though, I wonder if it would not be better to just omit the
movefunction entirely. It is a C++11 feature, and this library mostly implements C++03. Mixing and matching versions like this makes it harder to use other libraries (like https://github.com/hideakitai/ArxTypeTraits) to add the C++11 and newer bits on top of the C++03 bits provided by this library...