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