On 6/7/2015 7:31 AM, Rob Stewart wrote:
On June 6, 2015 3:30:54 PM EDT, Edward Diener
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.
If my interface to my library uses my macro system for a particular Boost library, and you interface to my library then you should use the same macro system for that interface. But outside that interface you can use what you want. This is absolutely no different from this situation: you are compiling in C++11 mode and using std::xxx and some Boost library uses boost::xxx instead in its interface. What do you do ? I honestly don't mind and do understand the opinion that a Boost library should always use another Boost library rather than its C++ standard library equivalent in its public interfaces as the LCD that will work with C++03 and C++11. I just don't think this scales well as more C++ programmers use C++11 and find themselves using the C++ standard libraries in their code. My macro system is an attempt to accomodate that situation in C++'s future, which I view as inevitable.
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.