You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 30, 2022. It is now read-only.
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.
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...
The text was updated successfully, but these errors were encountered:
The implementation was incorrect, and we are using our own
implementation already, so just remove it here.
See also arduino-libraries#12
on resolving this upstream.
From your argumentation it sounds like simply removing std::move would be the way to go.
In related news: we've been discussing internally about handing off maintenance of libraries to selected community members who might be interested in taking up the mantle of a maintainer. This library would be a prime example for this. Initially forked to serve an Arduino internal purposes (and because the original libraries were no longer maintained) the reason for having this library have become obsolete by now. For posterity: The purpose of this library was to support to run the ArduinoIoTCloud library on AVR.
Long story cut short: Are you, @matthijskooijman interested in taking up maintainer ship for this library, given that you are regularly reporting issues and providing PRs? This is of course pending approval by @alranel whom I'd hereby like to invite to voice his opinion on my suggestion.
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
-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 supportingstd::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...The text was updated successfully, but these errors were encountered: