Subject: [boost] [Move] BOOST_NO_RVALUE_REFERENCES - or so it thinks
From: John M. Dlugosz (mpbecey7gu_at_[hidden])
Date: 2014-02-08 15:37:21
Real-world software projects don't always get to use the latest stuff in a timely manner.
I'm working on some code that needs to work across several platforms, which generally
means programming to the least-common-denominator.
What I want to bring up in particular is the issue that the compiler may be more up to
date with C++11 than the libraries. Someone trying to use Boost on Android (IIRC) trying
to change the Boost config to tell it that C++11 support is available said it was like
playing "Whack-a-Mole", in that each change caused more problems elsewhere. It seems that
the overall issue is Compiler vs Library. Saying that rvalue references are available
doesn't mean that std::move, std::forward, etc. are available.
I threw together a move.h file that contains forward, move, and a few others taken exactly
from the standard — all one-liners. That lets people who know that the compiler really
does know what to do with && write code that uses them, just so long as they remember to
use the project's namespace and not std, or the multi-platform build coughs it back out.
I also successfully crossbred the unique_ptr implementation from libcxx-3.4 with Boost +
my own move.h namespace.
Now try putting a (real) move-only object into a boost::container::vector when Boost is
built with BOOST_NO_RVALUE_REFERENCES. Might I convince the powers-that-be to reconfigure
Boost with that #define removed? That could be done when upgrading Boost anyway, but it
seems to not work! Whack-a-mole. I didn't do it personally, but it appears that at the
very least Boost would need its own move.h and whatever odds and ends it assumes are
present. That would be quite easy since these little functions are just fancy casts and
you can mix code that calls different "implementations" of them. So Boost could always
use boost::move which turns into
static_cast<typename boost::remove_reference<T>::type&&>(t);
(as opposed to just 'using' the std::move) and other code doesn't care. That is, it would
not be necessary to configure "has std::move vs not have std::move" but just don't rely on
std::move at all.
In short, I don't know if it's just me, but most of the company jobs I've worked have
lagged behind, with upgrading the compiler and/or libs being a Big Deal, especially if
using outside code that's already compiled.
So, I want to raise the possibility that making Boost work with native rvalue references
but legacy (C++03) standard library would be useful to some significant population of
developers. #undef'ing BOOST_NO_RVALUE_REFERENCES in the config ought to just work, at
least on a lib by lib basis. I mean, it might be fine if some libs didn't handle that as
many people don't use every single lib in every project. Boost.Container is interesting
though because it is used to overcome legacy std::map etc. as one of its stated goals.
It's also good for avoiding platform compatibility issues when all platforms use the same
map class (e.g. the master build doesn't spit out failures as erase is void on some
platform but returned an iterator on the platform used to try the code before checking it in).
The current version of Clang as used for Mac and iPhone/iPad development has && working
even if you don't enable the C++11 dialect. So sneaking in some &&'s in a program doesn't
require any reconfiguration of the projects.
—John