Re: [boost] [type_traits][general] Best practice for inline namespaces?

Subject: Re: [boost] [type_traits][general] Best practice for inline namespaces?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-20 19:32:54

On 20 Jan 2015 at 11:01, Gavin Lambert wrote:

> On 19/01/2015 07:07, Andrey Semashev wrote:
> > On Sunday 18 January 2015 17:10:04 John Maddock wrote:
> >> I think you may have hit the nail on head there: are inline namespaces
> >> of any use for header-only code?

Definitely.

> > Yes, they are in general. Things like function, shared_ptr, any, variant are
> > often present in binary interfaces of user's code. Making these component
> > names versioned will make sure that user's ABI wont break if he (accidentally)
> > mix different versions of Boost or different configurations. But that's not
> > the case for libraries like TypeTraits or MPL.

I would have said the bigger benefit is that ABI *does* break when a 
version iterates. For example, you *want* a library compiled against 
Boost v1.54 to not link ever against Boost v1.55. On POSIX where the 
symbol namespace is global this is a very real concern as without 
inline namespacing loading libraries with slightly differing Boost 
dependencies will trample all over one another.

> It depends.  Both TypeTraits and MPL can appear in the user's header 
> files to select types for use in user code, including unit-to-unit 
> interfaces which are an inherent ABI boundary.
> 
> shared_ptr etc are *more* exposed, in that their size and memory layout 
> also forms part of the ABI contract (unlike TypeTraits and MPL, where 
> the internals are less critical), but if there is a chance that the 
> resulting type output of a TT/MPL metafunction can change from one 
> release to the next or for one compilation setting vs. another, then it 
> also becomes potentially ABI breaking.
> 
> It seems to be a common misconception 
> (http://www.boost.org/development/separate_compilation.html) that 
> header-only libraries are not subject to incompatible ABI issues. 
> That's simply not true, especially when the user is using multiple 
> ABI-affecting settings in their code.

As BindLib soon to be renamed to something else shows, you can also 
use inline namespaces to externally select implementations of Thread, 
Filesystem, Networking and any other internal library dependency. 
This makes much easier libraries which can link against either the 
C++ 11 STL or Boost or multiple versions of Boost, all in the same 
translation unit if needs be.

I would very strongly advise that all new Boost libraries should be 
required to version their API when inline namespace support is 
available, and that all existing Boost libraries be upgraded as soon 
as their maintainer can make it happen.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/