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

Subject: Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-06-07 06:22:26

On 07.06.2015 06:39, Edward Diener wrote:
> On 6/6/2015 7:23 PM, Andrey Semashev wrote:
>>
>> The macros don't abstract
>> away what implementation is being used - STL or Boost - because I have
>> to deal with linking anyway. That's why the solution is incomplete.
>
> I have repeated again and again that for built libraries, as opposed to
> header-only libraries, a system of distinct names for the same library
> depending on whether the library is compiled in C++03 mode or C++11 mode
> can solve this problem.

I don't see how.

>>> 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. If Boost ever goes to a more modular
>>> distribution all distribution of EDS_LIB must also include Boost regex.
>>
>> Why? EDS_LIB would depend on Boost.Regex but not include it.
>
> How in the world would EDS_LIB depend on Boost.Regex but not have it
> part of the distribution of EDS_LIB if we go with a modular Boost
> distribution where EDS_LIB could be distributed by itself with its
> dependencies ?

Huh? I didn't know we were going for that kind of modularity. My 
understanding was that modular Boost would consist of multiple 
independent libraries (which distribute only their own code) and a tool 
that is able to download a library and its dependencies.

If we're going to bundle a library and all its dependencies together 
then that's not the modular Boost I want to use or develop.

>>> Now let's suppose, using my macro system, I can distribute my library as
>>> EDS_LIB in C++03 mode or EDS_LIB_C11 in C++11 mode. My exported
>>> interface
>>> using regex is:
>>>
>>> #include <boost/config/cpp/regex.hpp>
>>> #include BOOST_CPP_REGEX_HDR
>>> void EdsFunction(BOOST_CPP_REGEX_NS::regex & rx);
>>>
>>> Now if you compile your library or application in C++03 mode you link
>>> with
>>> EDS_LIB and you get its dependency on Boost.regex. If you compile your
>>> library or application in C++11 mode you link with EDS_LIB_C11 and
>>> you no
>>> longer have its dependency on Boost.regex. In your application or
>>> library
>>> you use my macro system in order to pass the correct regex in either
>>> case
>>> without worrying about which it is:
>>>
>>> #include <boost/config/cpp/regex.hpp>
>>> #include BOOST_CPP_REGEX_HDR
>>>
>>> BOOST_CPP_REGEX_NS::regex myregex("Some regular expression");
>>> EdsFunction(myregex);
>>>
>>> Where is the ABI problem in this case ? ( rhetorical question )
>>
>> The ABI problem is right here. EDS_LIB, as it is distributed in a
>> Linux distro, is built in C++03, and it is incompatible with user's
>> code that is built in C++11. At least not in the way you describe.
>
> EDS_LIB distribution is not distributed for C++11 use. For that my
> previously mentioned EDS_LIB_C11 is distributed with its dependencies
> for C++11 use.

What exactly do you mean by "distribution"? Does it include library 
headers? Are these headers different in EDS_LIB and EDS_LIB_C11? If both 
are yes, do they not conflict?

>> My suggested approach would be to avoid both Boost.Regex and
>> std::regex in the binary interface - for example by passing strings in
>> the ABI. You can still use whatever regex you like in the API, or even
>> better - use concepts to accept any regex-like type, be that
>> std::regex, boost::regex or boost::xpressive::regex - whatever the
>> user happens to be using in his code.
>
> I know you are not kidding but I consider your solution "not optimal".
> Your solution is that two perfectly usable versions of regex exist but I
> need to manufacture another. Needless to say that is not my idea of
> programming in this situation.

Why would you have to manufacture one?

>>> How many other library dependencies does libstdc++ have ? Then ask
>>> yourself
>>> how many other library dependencies does any given Boost library have
>>> ? Have
>>> I made my point ?
>>
>> No, I don't think you did. How the number of dependencies have any
>> relevance to API/ABI stability?
>
> What does API/ABI stability mean in this context to you ?

For the course of this discussion it means that API/ABI do not depend on 
compiler options, including C++ mode.