Re: [boost] [outcome] non-interface-related concerns

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Deniz Bahadir (dbahadir_at_[hidden])
Date: 2017-05-27 18:41:43

Am 27.05.2017 um 18:08 schrieb Peter Dimov via Boost:
> Niall Douglas wrote:
> 
> [snip]
> 
>> Actually there is overwhelming evidence that Boost **users** do not 
>> want a dependency on Boost. But I've been saying that for years now.
> 
> Yes, and I already answered it, with your swiftly proceeding to ignore 
> my answer. Probably because you didn't understand it, which of course 
> means it's irrational.
> 
> To repeat, it's not possible for a Boost user to not want a dependency 
> on Boost. A Boost user already has Boost. This is tautological.
> 
> Not wanting a dependency on "Boost" is characteristic for people who 
> want to use a specific Boost library without any of the rest. This is 
> not the same thing, and it does not at all describe all Boost users, so 
> taking this (existing and legitimate) subset and talking about them as 
> Boost **users** is simply disingenuous.
> 
Maybe I can step in here as a Boost user who prefers to not have too 
many inter-Boost dependencies between the different Boost-libraries.

 From my point of view, I am fine with having the entire Boost 
collection available for my source, even though I would prefer a less 
monolithic distribution.
However, I would sometimes wish that some inter-boost dependencies would 
not exist or at least be not available in some certain situations.

For example, in our code-base at work we have compilers supporting C++11 
as a minimum and are already switching to C++14 as our base-level. 
Therefore we do not need any boost-provided classes that are already in 
the standard as e.g. Boost.SmartPtr, Boost.Move or Boost.Thread 
(although the latter supports some more functionality that we do not 
have in standard threads but which we are also not needing). If they can 
co-exist with the standard-versions that is ok but we would feel it 
would be better to get rid of them in such situations.

Another thing, that has big impact on our code-base is Boost.MPL. We are 
using Boost.MSM which itself uses Boost.MPL. And we had to extend the 
preprocessed MPL-containers to support more than the standard 50 
elements, because the state-machine built with Boost.MSM did require 
that. That however has impact on all other libraries that are using 
Boost.MPL, too. For example Boost.Flyweight and Boost.Multi_Index, which 
in our case do not need so many elements. Therefore their types consist 
mostly of mpl_::na which again results in very long type-names, so that 
some external tools (Valgrind.Massif comes to mind) cannot show the 
actual function-signature, because its internal type-name buffer gets 
filled with mpl_::nas. (Additionally, this might increase compile-times, 
too, although I did not measure that.)
Would there be no dependency of Boost.Flyweight on Boost.MPL this might 
have been easier for us. But I cannot tell, if it would have been 
feasible to "reinvent" the required Boost.MPL parts without having a 
dependency on it.

To get back to Outcome, I would recommend that is uses Boost.Config 
instead of a custom version of it because it seems to be quite useful, 
well tested and does not introduce many other inter-boost dependencies 
(as fas as I know).
However, dependencies to other Boost.Libraries might be less helpful 
because maybe just some small part might be required and instead one 
gets dependencies to a whole lot of other Boost-libraries which are 
unnecessary.

(You notice that I do not know really know which other dependencies 
there might be. I just wanted to explain the point of such Boost users 
who like the dependency-tree to be quite clean.)

Just my 2ct.

Deniz