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: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-14 02:15:00

On 5/13/2015 11:32 PM, Niall Douglas wrote:
> On 13 May 2015 at 19:21, Hartmut Kaiser wrote:
>
>>> 3. Is there a common theme in choice of library design and use of
>>> third party libraries?
>>
>> What would this information give you? Finding new 'design patterns'? This is
>> the only question I'd support going after as it would help other library
>> authors to take advantage from 'best practices' and 'lessons learnt'.
>
> You mean https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook?
>
>> You connect this analysis of 'C++11/14 mandatory libraries' (a
>> classification I find to be deeply troubling, btw) with 'rebooting Boost'.
>> Is that intended or just a coincidence?
>
> Two years ago I felt Boost should be rebooted for reasons.
>
> Now I know Boost is being rebooted by the new library authors.

"Rebooted" meaning what ?

>
> I had suspected it before, but now I know. I think it'll be a lot
> more obvious next year when the new authors have seen community
> review.
>
> In the end it doesn't matter what you or I or anyone else thinks what
> should be the case.

Of course it matters, because 'we' are part of the "collective vote" of 
those developing libraries.

> What matters is the collective vote by those
> writing libraries: their design choices, their preferences, and their
> code. I'd like to think I persuaded everyone to adopt my arguments,
> but in truth I think it was always going that way no matter anything
> I said.

I am actually laughing because you are so over the top in your assurance 
that everyone sees things in your own way, as if it were a fait accompli.

>
>> Regardless, my impression deepens, that all of this is an attempt to take
>> over Boost for your own (commercial) interests and to force your own library
>> onto everybody else. An attempt which I will not support.
>
> Heh. I would just *love* to know what interests, especially
> commercial, those might be.
>
> The truth is this Hartmut:
>
> 1. I wanted AFIO standalone. The only Boost library I knew of capable
> of standalone is ASIO. ASIO achieves standalone though a fairly
> laborious macro based dependency injection method which either
> injects the STL11 or Boost into the asio namespace.
>
> 2. I didn't want all that brittle manually written machinery ASIO
> uses. I felt using C++ 11 and a bit of libclang AST programming I
> could largely automate it and save myself a ton of work.
>
> 3. As I implemented it, I realised the same mechanism could do
> version binding too. And that it would likely be extremely useful to
> any other Boost author wanting both standalone and Boost options and
> to let them evolve their library without worrying about dependency
> breakage as much.
>
> 4. APIBind is *ridiculously* simple. People seem to think it some big
> complex thing. All it is is a set of conventions for naming really.
> C++ 11 and programmer discipline takes care of the rest.
>
> Hence we are where we are. I don't claim APIBind is finished. I do
> claim it's good enough for my purposes, and with a bit of extra work
> it probably would be good enough for other people too.

Please document APIBind as fully as you can and I, and probably many 
others, will be happy to look at it and see what it is about.

>
> It's up to each library maintainer if they wish to use APIBind, or do
> as Chris did with ASIO and do it all by hand. Or ignore dependency
> injection, and use no Boost at all.

How about the choice of not wishing to have a standalone library and use 
whatever of Boost or anything else one wants ?

> Whatever happens, it is extremely
> clear to me a C++ 11/14 only Boost distro is coming simply through
> the authors in question continuing to support standalone modular use.
> Even if I were to vanish tomorrow.

Let it come then. I doubt that current Boost will go away.

Boost currently consists of some 125+ libraries.  Perhaps I am 
misinterpreting your attitude, but you seem to think that new C++ 
library developers have no use for any of those libraries and will find 
all they need to create their libraries in C++11/C++14 and its standard 
libraries. I do not find that to be true at all and I see nothing which 
supports those facts in libraries proposed for inclusion into Boost.

I have nothing against those who want to create libraries that require 
C++11/C++14 implementations and still be part of Boost. If their design 
means that they do not need to depend on any current Boost libraries 
that's fine also. But to limit C++ library developers to only what is in 
the C++ standard library, and to place all of the usefulness of Boost 
libraries off limits to their development efforts, seems a foolishly 
willful effort for no gain at all and a great loss of potential 
functionality. I do not know if that is what you are proposing, or 
whether it is called Boost 2.0 or whatever. But if it is, it is not a 
goal of software development which I would ever pursue.

I have already worked in enough programming jobs as a computer 
consultant where some boss, sometimes knowing next to nothing about 
software development, decides that useful software libraries should not 
be used. Inevitably inferior technologies are chosen which are written 
from scratch, wasting time, programming effort, leading to a poorer 
design, and a buggier product.

Software dependencies are always a problem which must be solved by an 
intelligent system to deal with them. But they are far better than 
having to rewrite code which already exists, has been tested, and found
useful, just become someone might fear that a dependency on some useful 
library will create unnamed and unimagined problems in the future.