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.