Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries

Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries
From: John Maddock (jz.maddock_at_[hidden])
Date: 2015-05-15 12:51:07

>> Some time back I changed Math to use std::tuple internally when
>> available, now we're starting the process of exposing that to end users
>> so they can use *any* suitable tuple type (including the 2 different
>> versions in Boost, plus tr1 and std versions).  The code doesn't care
>> which, that's what generic code is for ;)
>>
>> For sure adding C++ support to older libraries may sometimes seem slow -
>> but it's demand driven - unless there's a really good case for changing
>> things lib authors are understandably cautious (and don't even get me
>> started on noexcept specifiers!!)
>>
>> Basically if it's working perfectly well now, there has to be a good
>> reason for major architectural changes, and those have to be handled on
>> a case by case basis.
> That's just about the worst way to add C++ 11 support. You get
> problems with ABI conflicts, violation of ODR, and additional bloat.
>
> As an absolute minimum, you need to combine such macros switching
> std::tuple usage into custom namespace. This prevents collision,
> violation of ODR, though does little for bloat.
>
> APIBind does exactly the above - custom namespace generation via
> macro programming, using inline namespaces to make this underlying
> solution hidden to code using your library.

I think you misunderstood what I meant, the Math exposing tuples in the 
interface doesn't switch between implementations: rather it's 
implementation agnostic because it works with the "concept" of a tuple, 
not a particular implementation.  Users will chose which to use based on 
what they're using elsewhere in their code.  None of the issues above 
apply IMO.

John.