Re: [boost] C++03 / C++11 compatibility question for compiled libraries

Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2018-02-10 10:20:06

Le 09.02.18 à 19:45, John Maddock via Boost a écrit :
> 
> 
> On 08/02/2018 08:50, Raffi Enficiaud via Boost wrote:
>> Dear list,
>>
>> I have a technical question I do not know how to address, and I would
>> like to know how people deal with this.
>>
>> To put things in the background: boost.test uses heavily boost::function
>> and boost::bind, however I would like to use in some circumstances
>> std::function and std::bind, which are, for instance, variadic.
> 
> Trying to get back to the case in point... is there any reason not to
> support both in the binary library?
> 
> ie
> 
> virtual int operator()( boost::function<int ()> const& F ) = 0;
> virtual int operator()( std::function<int ()> const& F ) = 0;
> 
> One of these can presumably simply call the other internally since a
> boost::function should be storable in a std::function and vice versa?

I agree. However I have several doubts that this might work in the long
term. One problem I see is that, if those types are somehow "equivalent"
(purposely not defining what it means), then I believe that it may
happen that we have type ambiguity at compilation time.

The other concern I have is more about strategic. Since C++11,
std::function is for me - de facto - the **upstream**, and whatever
boost::function does:

* should follow the standard for compatibility and feature set
* is more or less disallowed to provide any type of extensions to this
standard as it may confuse users.

So, again, I do not see any superior solution, but betting that
boost::function will handle smells like the wrong choice somehow.

Also, I believe that all those compatibility issues between different
implementations of say std::whatever (ABI differences between C++11,
C++42 etc), are already - or should be - handled by library implementers
much better than what boost developers can provide: those people know
their compiler and library best. Looking only at this thread shows how
much boost developers' community is not equipped to handled this problem
(no offense, just a cold factual sum up :) ).

> Except we can't make the std::function variant virtual as disabling it
> in C++03 mode would change the vtable layout... or can we just make sure
> it's the last virtual function declared?  Or else maybe only one of
> these needs to be virtual and the other can be a one line forwarder?

Yes, and all this renders the API very hard to manage for the users (and
I am not mentioning the developer in this case).

> I don't know enough about Boost.Tests internals to know the answer to
> any of these questions, but:

So far, I purposely discarded the implementation. My only concern is the
API and the compatibility of the produced libraries.

> * This topic is going to keep coming up - it may be 03 vs 11 or 14
> today, but next week/year it'll be 14 vs 17 or 17 vs 20.  And,

Indeed. Having say, boost.test-C++03 and boost.test-C++11 is a
possibility. But where does this end? What is a good partition wrt.
compiler set? Coming back to boost.test, I believe that I may loose a
lot of my clients splitting up, OTOH I may gain new people: I simply do
not know today which strategy is good for the library itself.

> * Somehow we need to find strategies for dealing with this.
> 
> Not helping much, John.

Not true :)

Hand to hand,
Raffi