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

Subject: Re: [boost] [Config] Support for switching between std:: andboost:: equivalents.
From: John Maddock (jz.maddock_at_[hidden])
Date: 2015-06-07 13:04:14

On 07/06/2015 15:36, Peter Dimov wrote:
> Edward Diener wrote:
>> Most of the talk about the problems of my macro system presupposes 
>> that programmers using Boost will mistakenly try to use a C++11 
>> version of a library during a C++03 mode build and vice versa, and 
>> therefore the system must be flawed.
>
> This was some of the talk but I'm not sure about "most". A substantial 
> part of the talk was about programmers wanting to use boost::regex 
> even when the compiler happens to be in C++11 mode. In other words, 
> talk that challenges your assumption that
>
>> If the end-user of my library is compiling in C++11 mode is it more 
>> likely that his use of regex will be std::regex or boost::regex ? IMO 
>> it is the former.
>
> There are several good reasons to prefer boost::regex. First, the one 
> I pointed out, you want to maintain a single code base that compiles 
> under C++03 and C++11. Second, you want to use boost::regex's 
> extensions that std::regex doesn't have. Third, you want predictable 
> performance that is independent of the standard library in use.
>
Right.  But if lib X prefers/needs to use the Boost version always, they 
don't have to use this mechanism.
> On the other side of the coin, we have the desire to avoid use of 
> Boost when use of standard facilities would suffice, which is real and 
> legitimate. However, in my experience at least, this desire is only 
> strong when you can avoid use of Boost _altogether_, which is not the 
> case under discussion.
Right, we're nowhere near having a package manager that's smart enough 
to avoid dependence on boost::whatever if the user tells it they have a 
C++11 compiler.

I guess my concerns are somewhat different from those already expressed:

* I'm not sure that this adds much over the existing macros 
BOOST_NO_CXX11_HDR_REGEX etc.
* If this evolved into a more "complete" solution, then (a) It doesn't 
belong in Config (too many dependencies), and (b) I would worry that we 
repeat the mistake of Boost.TR1 - which is to say creating that 
particular unmaintainable monster it in the first place -just ask the 
author ;)
* Folks are correct to be concerned about ABI issues: we not that long 
ago changed 'nix installs to install "one true binary" for each library 
as there was *very* strong user preference for that. Splitting into '03 
and '11 binaries is IMO a significant retrograde step.  If you do that 
expect endless newbie support requests wondering why things don't work.

On the other hand:

* I can see a legitimate use for this as a library internal (rather like 
what Math does with std::tuple and boost::tuple).
* The need to have different linking requirements in Boost.Build is a 
solved issue - just use check_target_builds to set the dependency.

So... I guess what I would like to see expressed, is what are the 
concrete use cases for this?  What do *you* want to use it for?

And finally, you are aware that there are 3 tuples available? boost::, 
fusion:: and std::, and they they all are slightly different?  Oh and 
std::tr1::tuple too ;)

What I suspect we will see more of, is libraries becoming implementation 
agnostic - "give me something that looks like a 
tuple/thread/future/function and I'll go off and do the right thing".  
The latest Math code does that with tuple types, and it was a pain in 
the neck to get working (or possibly I was just being dense at the 
time), certainly the hoops you have to jump through to support that go 
way beyond the scope of this addition.

Regards, John.