Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk