On 5/02/2016 04:22, Niall Douglas wrote:
On 4 Feb 2016 at 14:45, Sam Kellett wrote:
redefining a macro in somebody else's 'namespace' is akin to opening up the std namespace to redefine vector.
This is exactly what my Boost-lite emulation already does.
The problem is when you include my stuff first and then include Boost without telling my stuff you actually want to use Boost, then Boost's definitions collide with my emulated ones.
If Boost did as you suggested there would be no warnings, and I'm defining the same functionally speaking thing as Boost is so there should be no breakage (insert many caveats omitted for brevity here).
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).