Boost logo

Boost :

Subject: Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-06-05 21:07:20


On 6/5/2015 6:35 PM, Andrey Semashev wrote:
> On Friday 05 June 2015 17:05:08 Edward Diener wrote:
>> On 6/5/2015 3:37 PM, Andrey Semashev wrote:
>>>
>>> 1. What if the Boost version requires linking with a built library? These
>>> headers won't be able to hide that.
>>
>> You are correct. But what are the issues about linking to a Boost
>> library which needs to be addressed as you see it ?
>>
>> Notice that anything necessary to linking to a Boost library can be
>> figured out macro-wise for a given library by first currently testing
>> BOOST_CPP_HAS_XXX for 0 to determine that it is the Boost library which
>> will be used. Of course some other BOOST_CPP_XXX macro would need to be
>> added to specify whether the Boost library needs to be linked or not. So
>> if there is anything which could be automated as part of the source code
>> to automate linking I should be able to automatically configure it
>> using macros also. As an expansion of the basic set of macros which are
>> offered for each library, if the solution to linking is a generic
>> solution I do not mind adding it in. But let's first identify the
>> problem before we can identify any possible generic solution.
>
> In general, you won't get away with just macros, as autolinking is only
> present in MSVC & friends. This would also affect build system scripts.
>
> Suppose I'm a (Boost) library writer; the library has a compiled part and I'm
> writing a Makefile/Jamfile. If I'm using these macros, I still have to know
> when to link and when not to link with Boost libs. This can be rather tricky
> as not only compiler versions should be checked but also their options; and it
> also needs to be in sync with Boost.Config. The same happens when I'm a user
> of a (Boost) library that uses these macros, only it becomes more difficult to
> be in sync with Boost.Config. My point is that since these macros don't
> actually abstract me away from the configuration, why would I use them?

They abstract you away from having to write complicated code which
caters to whether or not a C++ standard library equivalent to a Boost
library is available or not. They don't relieve the responsibility of a
built library from naming itself in such a way that those linking with
the library can do so successfully if auto-linking is not available.

>
> Arguably, this problem goes away if the macros only handle components which
> are header-only in Boost.
>
>>> 2. I'm worried if these tools will be used in Boost libraries in a way
>>> that
>>> affects library API/ABI. What if one library uses these tools and the
>>> other
>>> doesn't - will these libraries be able to interoperate? Or is it a user's
>>> problem? There is also the possibility that Boost is built in C++03 mode
>>> and the user builds his code in C++11. I think this will be most apparent
>>> with utilities like shared_ptr and function, which are often present in
>>> the interfaces.

The problem goes beyond the use of my macro system. Are we going to give
library developers the choice of whether they can use the C++ standard
library equivalent to a Boost library or not ? Please see my answer to
this at the emnd of my response.

>>
>> Its no different from some Boost library using the C++ standard version
>> of, let's say, std::function because it is available and another library
>> using boost::function. Is API/ABI compatibility affected ? If so that
>> has to be taken into account if you use those libraries internally.
>> Suppose library X is compiled using C++11 mode and your own library Y,
>> which uses library X as a dependency, is compiled without C++11 mode.
>
> It's more likely that Boost is compiled in one mode and distributed in a
> standard package (say, with a Linux distro) and I'm building my app locally
> with that Boost. Most Linux distros build Boost with default compiler options
> which means C++03. If these macros affect Boost libraries ABI I will no longer
> be able to build my app in C++11 mode.

The macros don't determine the mode; compiler options do that. I believe
Boost is going to have to work out anyway, if it has not already done
so, a difference in final naming between a library built with or without
C++11/C++14/C++17 support if that library supports building in more than
one C++ mode.

>
>> Again those factors of interoperability between the libraries must be
>> taken into account. Using my macros is not going to change any of that,
>> and my macro system cannot solve that problem, or make it more or less
>> than if the macro system I propose were not used at all.
>
> As Peter noted, having these macros in Boost.Config can be seen as
> encouragement to use. And when used improperly they can cause real problems.
>
> So far I'm seeing these macros only applicable under the following conditions:
>
> a) the macros can be used in header-only libraries or concealed in the
> compiled part of the library without exposing it to API/ABI, and
>
> b) only when these macros allow to switch between STL and header-only Boost
> alternatives (not compiled ones).
>
> I'm not sure how to enforce these restrictions and I'm not sure adding them
> without doing something about their dangerous use is a good idea. Sorry if I'm
> not being helpful here.

Arguing that a facility is bad because it makes it easier to use either
a C++ standard library equivalent to a Boost library or the Boost
library itself, as you and Peter have done, is counterproductive IMO.
The same problems would exist as soon as anyone decides to use one or
the other in their code even without my macros. I can't view it as being
better to only use Boost libraries in Boost library code simply because
it creates a single variant of a library. Eventually people will become
tired of not having the ability to use C++ standard library equivalents
in Boost code, and this will become more so if Boost moves to a more
modular distribution system. What will you tell people ? That they must
hard-code whether to use a Boost library or a C++ standard equivalent
library in their code ? And if the C++ standard library equivalent is
not available their library must be unusable in that environment ? I
don't think Boost is going to get very far in that direction.

I acknowledge the concerns which you have with a built library which can
be compiled in different C++ modes. My point of view is different in
that Boost has to face the fact that for any given library XXX it may
want to use a Boost library in one C++ mode, presumably C++03, and the
C++ standard equivalent of that Boost library in another C++ mode,
presumably C++11 or above. For this different naming conventions for
such a dual mode ( or more ) built library has to be created to
accomodate the situation. Either that or the library itself must be
treated under a different name for each mode in which it can be built,
but that's not a problem which my macro system itself can solve.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk