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: Viktor Kirilov (vik.kirilov_at_[hidden])
Date: 2015-05-14 12:29:55

I absolutely agree with Niall for what it's worth.

On Thu, May 14, 2015 at 7:10 PM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> On 14 May 2015 at 10:57, Thomas Trummer wrote:
>
> > * The talk isn’t really about future C++ libraries but to prove a
> > point. This isn’t an issue per se but I wish people would be upfront
> > instead of using bait and switch tactics.
>
> Bait and switch is a classic feature of C++ Now talks. It is a
> conference of experts presenting to experts. We're not here to attend
> tutorials. We're here to see something different to the other big C++
> conferences around the world, and that's why all the experts keep
> coming back to Aspen.
>
> I submitted almost the same topic for CppCon, but it's totally
> different content. For CppCon it's just a set of taster code examples
> using the libraries, almost a workshop.
>
> > * Two out of the five libraries used as evidence are from the same
> > author as the talk. That leaves only three.
>
> Actually I looked at 15 libraries, 10 in detail. Indeed two are mine,
> and about five have code or ideas from me in them.
>
> > > Everybody avoids Boost.Test
> > Are they really avoiding it or this is just a result of starting
> > outside of Boost and not being part of Boost yet. Using asserts is
> > more of a poor engineering practice than saying anything about
> > Boost.Test.
>
> Yes they are avoiding Boost.Test. The authors themselves may chime in
> here to confirm.
>
> > > Most avoid Boost.Build
> > Again. Are they really avoiding it or this is just a result of
> > starting outside of Boost and not being part of Boost yet. Getting
> > into Boost will result in using Boost.Build to be part of the whole
> > regression infrastructure. I’m pretty sure no library author would
> > object to that.
>
> Actually they do. They want to use cmake. Not Boost.Build. Again, the
> authors may chime in here to confirm.
>
> > > Everybody tries to use as little Boost as possible
> > Are they really avoiding other Boost libraries because of some problem
> > or don’t they just require other libraries? From the descriptions of
> > the libraries that actually seems quit plausible.
>
> Boost 1.x is obsolete.
>
> It is obsolete because enough of Boost 1.x is now in the STL that you
> no longer need to use Boost 1.x.
>
> It's also monolithic, and has a long list of structural problems.
> About half its libraries are undermaintained or not maintained. Many
> of the new authors wish their code as far away from it as possible
> because of the code smell. Quite frankly, as STL implementations get
> ever better, they are now better maintained and are of higher quality
> than Boost. In the end, STLs have a ton of full time engineers
> tending to them, Boost does not.
>
> Again, authors may wish to chime in or not themselves about their
> views on the matter.
>
> > > All the libraries reviewed are ivory towers
> > This is just repeating the same point. Boost libraries cover a lot of
> > different areas so some of them are self-contained others have lots of
> > dependencies. Though, everybody would probably agree that it’s better
> > to have Boost.Atomic than five libraries implementing it itself.
>
> I've actually changed my talk in response to this.
>
> > * The “Best C++ 11/14 Practices Handbook” has nothing to do with C++
> > (except one or two points). That doesn’t mean it’s wrong or bad but
> > it’s just software engineering in general.
>
> You might want to read it in detail instead of just the headings.
> It's very C++ specific, and fairly Boost specific. I give links of
> use examples throughout, all of which are to C++ projects or C++
> code. Many of the tools proposed are C++ specific too.
>
> > > Clear design and philosophical division between C++ 11 libs and 03 libs
> > No evidence was presented for this. Arguing that future Boost
> > libraries, even if they are C++ 11 only, are not going to depend on
> > existing libraries is quite silly. I don’t see anyone object to use
> > Boost.Build when getting accepted into Boost. If libraries use
> > Boost.Test or not isn’t really an issue as long as the tests work with
> > the testing infrastructure.
> >
> > > Obvious natural split for a C++11 only Boost 2.0
> > Obvious to whom? There will be libraries in the future that require
> > C++11. This doesn’t create a problem for anyone. Neither does it
> > require a split away from Boost.
>
> I have adjusted my presentation to clarify what I meant here.
>
> Thanks for the feedback. It was useful.
>
> Niall
>
> --
> ned Productions Limited Consulting
> http://www.nedproductions.biz/
> http://ie.linkedin.com/in/nialldouglas/
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>