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. There is also no risk at all of link problems because of the namespace binds. You may or may not remember Gavin that BindLib does explicit hard binding of a specific version of a dependent library into the destination namespace, so when Outcome is configured to use an emulation of Boost.X, it *always* uses that with no effect nor consequence on any other use of the real Boost.X in the same translation unit. AFIO v1 has a unit test where an AFIO built using emulated Boost is compiled alongside an AFIO built using real Boost in the same translation unit. It all compiles and links and passes all unit tests perfectly. This stuff is very safe and reliable and coexists happily with all other code. All the normal assumptions about stuff colliding even in the same translation unit does not apply for any of the BindLib based libraries. If the C preprocessor namespace were as configurable as the C++ namespace, I could prevent the above (probably harmless) warnings, but the language support just isn't there so we are at where we are at. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/