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

Subject: Re: [boost] [Config] Support for switching between std:: and boost:: equivalents.
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-06-07 07:31:04

On June 6, 2015 3:30:54 PM EDT, Edward Diener <eldiener_at_[hidden]> wrote:
> On 6/6/2015 12:14 PM, Niall Douglas wrote:
> > On 5 Jun 2015 at 5:30, Edward Diener wrote:
> >
> > My only real worry is the ABI problems. You need to permute the
> > symbols being linked to avoid config mismatches colliding in an
> > unhelpful way.
> 
> The issue as far as ABI comes down to the ability of using such a 
> dual-mode library that is a built library and is not a header only
> library.
> 
> My point of view is that Boost needs to establish a way so that a 
> library built in C++03 mode could be named slightly differently from
> the 
> same library built in C++11 mode. We already have a system in place 
> which can name a library differently depending on whether it uses the 
> dynamic or static RTL of its implementation, or whether the library 
> itself is a static lib or a shared lib, among other naming
> conventions. 
> What I am positing for a built library is that the developer of that 
> library should have the ability to specify that his library have a 
> different name depending on whether it is C++03 or C++11 mode, and
> that 
> this choice should work so that the correct name is used during both a
> 
> link of the library and when that library is being used by another
> library.

I see a problem of combinations here. If a given library depends upon several different boost/std namespace components, it will probably switch among them consistently (all Boost or all Standard Library). But if that library always chooses to use a Boost library to get some extension it provides, and that library switches things incompatibly with the first library (or doesn't switch at all), problems will ensue.

These problems might be checked at runtime via version tests. The symbol check Niall mentions below is similar. At any rate, a library naming convention won't solve the problem unless there's a way to poison combining them in the wrong way.

> > Perhaps for each config macro have during build the library output
> an
> > extern dll visible empty function with a mangled name representing
> > the config. On use, import and use that function. This should
> > generate link errors if one is trying to use a config against a
> > binary not built the same way.

___
Rob

(Sent from my portable computation engine)