Subject: Re: [boost] Curiousity question
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-10-13 22:36:44
On 10/13/2016 5:45 PM, Gavin Lambert wrote:
> On 14/10/2016 06:46, Edward Diener wrote:
>> Point taken. I am considering a stand-alone cxx_dual, but its reliance
>> on Boost Config is a pretty big burden to overcome unless I incorporate
>> much Boost Config logic in my own code, which I am not sanguine about
>> doing. Boost Config is a magnificent achievement, without which cxx_dual
>> does not exist. I acknowkledge that in the doc.
>
> Perhaps it's another argument for truly-modular Boost, where you can
> download individual libraries rather than a monolithic release.
There are many other arguments for what you suggest, not just cxx-dual.
But without a versioning infrastructure, where each library has not only
its own versioning information but can check if it is compatible with
the versioning information of all its dependencies, I doubt it will
succeed. Just randomly assuming that because Boost libary X depends on
Boost library Y and the end-user places some release of Boost library X
somewhere and some release of Boost library Y in the same "somewhere"
directory structure where library X can find it, does not mean that
Boost library X will work with Boost library Y.
>
> I never really have any issues with including Boost code in desktop
> build environments, but it becomes a harder sell when writing embedded
> or cross-compiled code. (I usually still do it anyway, typically to
> plug holes in the libc, but it requires more justification.)
I have actually worked as a consultant for companies in programming
groups, working on desktop applications and libraries, where the use of
Boost was not considered, even for just header-only libraries, because
the monolithic nature of the Boost distribution was not acceptable to
the company. Many of these companies would rather spend literally
millions of dollars rolling their own solutions, for which Boost already
provided libraries that worked much better than anything that they could
do. This is just dumb but this is how many companies for which I have
worked as a consultant actually think.
I don't think that the solution for cxx_dual, that it should not be part
of a Boost distribution to be considered usable, is any more or less
true of any other Boost library. But like you say if there were a
workable modular Boost-like distribution of libraries cxx_dual would
benefit from it like lots of other Boost libraries also would. While I
understand Peter's point I do not think that it should mitigate against
the ease of use of dual libraries in cxx_dual if that is what anybody
really wants to do.
However from asking my question and receiving your answer and others I
can see that the problem which I have solved for myself in cxx_dual is
not a problem at all for the large majority of library developers who
have answered my OP.