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
const& F ) = 0; virtual int operator()( std::function 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