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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-15 11:58:11

On 15 May 2015 at 8:59, John Maddock wrote:

> > This isn't the claim.
> 
> Well that's certainly how it read to me, in fact it seemed to me that 
> you were originally advocating "lets throw everything away and start again".

That's where I was two years ago, even a year ago.

I now have a viable migration path from 03 to modular 14 for existing 
Boost libraries. For those library maintainers which invest the 
effort to make their code base support both, I see no reason their 
library won't continue into the long term. If they remain wedded to 
03 and refuse to support any 11 or any modularity, well I believe the 
users will vote with their feet on that over time.

> > The claim is that so long as the libraries in
> > Boost which depend on STL11 equivalents cannot use the STL11
> > equivalent, they are suffering from at least these problems:
> >
> > 1. An inability to easily interoperate with code which uses the STL11
> > primitives e.g. std::future.
> Yes that can be an issue, but it's easily addressed via Boost.Config 
> #ifdef's.
> 
> 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.

> > 2. A compile time and binary bloat deficiency, sometimes very
> > substantial.
> Really?  Why would the Boost versions be so much larger than the std 
> versions?  Can you give an example?

It's mostly a case of duplication of functionality, but as a single 
example I can see that a move capturing c++ 14 lambda is going to be 
ton more efficient than a std::function built using std::bind. C++ 11 
is also much better at eliding unnecessary code.

> > 4. A potential deficiency in reliability and quality, as the STL11
> > Boost equivalents are probably not as well tested, audited, and
> > maintained as the STL11 editions simply due to resources invested.
> I disagree strongly, often the Boost versions are mature, portable, 
> heavily tested and in widespread use.  IMO we haven't even begun to 
> shake out all the bugs in the some of the std versions yet.

Mature yes. The rest utterly no. The STL maintainers on this list may 
chime in here, I'll leave it to them.

> Do you realise that GCC completed it's C++11 support only in the most 
> recent 5.1 release?  Or that <regex> was a non-functioning stub until 4.9?

I probably have a better idea than you. I am at C++ Now right now 
after all, and these issues have come up in *detail* ... :)

> And I haven't even even mentioned Boost-specific extensions - if you 
> need full Perl compatibility then it's pcre or Boost.Regex, std::regex 
> doesn't get there for example.

Sure. If you really need the Boost edition, you're going to need it 
no matter what. I'm talking about the 80-90% of use cases not using 
any of the extended functionality, or able to not use the extended 
functionality.

Niall

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