Re: [boost] [Config] Support for switching between std:: andboost:: equivalents.

Subject: Re: [boost] [Config] Support for switching between std:: andboost:: equivalents.
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-06 18:46:40

On 6/6/2015 5:05 PM, Peter Dimov wrote:
> Edward Diener wrote:
>> Let me give a very simple practical use case and this will illustrate
>> what I am trying to discuss.
>>
>> I develop library EDS_LIB and it is a Boost library which must be
>> built as a library and is not header-only, and my library uses regex
>> in some interface it exports.
>>
>> I have a decision to make: do I use Boost.regex and therefore work in
>> any C++ mode or do I use std::regex and therefore works only in C++11
>> mode ( which I will assume supports the std::regex library ). Most
>> people will say to use Boost.regex and be able to support any mode.
>> Fair enough, but now EDS_LIB depends on Boost regex.
>
> And what is the use case in which you don't have Boost.Regex but do have
> Boost.Config so that you can use your proposed mechanism?

That use case does not currently exist. But I am missing your point.

The mechanism says that if std::regex exists, use it instead of 
boost::regex. If std::regex does not exist use boost::regex instead. If 
I don't have a dependency on boost::regex and std::regex supplies all my 
module's needs is it not better to use std::regex, so that in a future 
modular Boost distribution based system I will not have to distribute 
boost::regex with my library ?

>
> If your library is not part of the Boost distribution, it might make
> sense for your library to support building without Boost, in which case
> one would expect your library to not need Boost.Config, wouldn't one?

I can have my macros not be part of Boost.Config but why would I do that 
? The macros work to choose either a Boost library or its C++ standard 
equivalent at compile time. The macros also use what is in Boost.config 
to make that choice. If the macros are dependent on Boost.Config why 
should they not be a part of Boost.config ?

>
> And if your library is part of the Boost distribution, one would expect
> Boost.Regex to also be present, wouldn't one?

Of course.

There is some sort of disconnect here, because I can't make out what you 
are getting at.

>
>> If Boost ever goes to a more modular distribution all distribution of
>> EDS_LIB must also include Boost regex.
>
> Right. But this isn't the case now.

Correct. You can say that now my macros don't buy you anything and the 
right choice is to always use Boost libraries instead of their C++11 
standard library equivalents. But of course if you are one of those 
people who see unneeded dependencies on other Boost libraries as a 
negative thing, you could argue that cutting down on those dependencies, 
by using their C++11 standard equivalents when compiling in C++11 mode, 
is a positive thing.

My argument is that if Boost ever goes to a modular Boost distribution 
system, where a single library, whether built ot header-only, is 
distributed with its dependencies, you could use my macro system so that 
you can distribute the library without having to distribute, as in the 
example, boost::regex with it when the library is going to be used in 
C++11 mode. And you do that without having to change your code in any way.

I can fully understand the viewpoint which says that in our current 
Boost distribution it does not mean anything to reduce a dependency on 
Boost libraries when compiled in C++11 mode, since the library is 
already there in the distribution. For those people, who are probably 
the vast majority, you simple decide to use the Boost library, even in 
C++11 mode, and you are done with it, and my macro system is a waste of 
time and an added complication. My solution is for the future, if and 
when we distribute Boost libraries independently. Somebody, I forget 
who, wrote a Boost tool for extracting a library and its dependencies 
into a sort of mini-distribution. So somebody else is thinking somewhat 
along the lines I was thinking when I came up with my macro solution, 
that allowing a single library to be used with its dependencies might be 
a good thing, and therefore reducing its dependencies without 
impairing/changing its functionality helps that situation.