On 4 February 2016 at 23:00, Niall Douglas
On 5 Feb 2016 at 11:34, Gavin Lambert wrote:
I think what Sam was trying to get at is that instead of declaring things in the boost namespace, your abstraction layer should declare things in some unique namespace (mostly as typedefs and usings from either std:: or boost:: as appropriate), and then your code that depends on this should exclusively use your abstraction layer namespace, not the boost namespace.
This will avoid generating any conflicts or warnings even if Boost and your emulation are included at the same time. Though the potential downside is that in cases where you want it to use the Boost version, it might not due to the include order, and you could end up with some components using Boost and others not (although that should generate link errors).
Regarding the macro namespace collision, it's a fair point, but as I have said more than once now the semantic meaning of the macros is the same. So BOOST_RV_REF or whatever means and does the exact same thing, and the warnings are only occurring because the library is being configured incorrectly anyway. If you configured it right, no warnings
what's the disadvantage of using your own namespace? afaics it is exactly the same only without the possibility of a namespace collision.