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
#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
#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.