[boost] [Move] BOOST_NO_RVALUE_REFERENCES - or so it thinks

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