$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [type_traits][general] Best practice for inline namespaces?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-01-19 17:01:14
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?
>
> 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.
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.