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.