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:
>> 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
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
(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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk