Re: [boost] Curiousity question

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.