Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-02-04 18:00:29

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/