Boost logo

Boost :

Subject: Re: [boost] Cxx dual library
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-06-03 16:34:34

On 6/3/2016 3:27 PM, Michael Caisse wrote:
> On 6/3/16 11:30, Edward Diener wrote:
>> On 6/3/2016 11:17 AM, Thomas Heller wrote:
> <snip>
>>> Personally, I'm not a big fan of such a solution, especially when those
>>> macros "leak" into the public interface. We had a similar interface
>>> which
>>> would automatically switch between std and boost function. The result
>>> looked nice at first sight, however the subtle differences between the
>>> two
>>> led to various problems, one of which was that documenting the public
>>> interfaces containing this macro was very difficult, where does it
>>> point to
>>> know? Where should we send users to who look for more information about
>>> this function type? Should they be aware of both? Switching compilers or
>>> even boost version and now suddenly everything seems broken?
>>> The solution for us was to just decide which one to use and go with it,
>>> setting the requirements to the used standard library/boost version as
>>> needed.
>> You are not being very specific about the problems you encountered, so
>> it is really hard to respond to them.
> Hi Edward -
> I can provide an example why we don't allow this type of thing at Ciere
> and why I'm opposed to automatic selection of implementation in Boost
> libraries [1].
> Years ago I had a problem with the is_pod type trait. MSVC and gcc were
> providing different answers in some situations. What I needed was
> consistency. The boost::is_pod was consistent. However, a boost::is_pod
> implementation that utilizes the vendor supplied implementation if there
> is one defeats my need for consistent behaviour.
> I don't want Boost libraries making choices such as pulling in the
> vendor supplied implementation. If I wanted the vendor supplied
> implementation, I would have included it myself.

There are 28 different dual libraries in CXXD. You can decide to use
CXXD for any one of those 28 different dual libraries, or not use it at
all. CXXD does NOT force you to use any of the dual libraries in whi9ch
you have no interest just to use CXXD for any one of them.

Suppose you write a library and choose Boost.function and the end-user's
of your library is using std::function all over the place. Do you feel
good telling him that he has to convert his uses of the function
implementation to accomodate you ?

> michael
> 1. - Your proposed library is a bit different. Switching is the purpose
> of the library. It isn't a TR1-like Boost library that is switching
> implementation based on compiler availability.

CXXD is a library that is switching implementation based on
availability. By default it chooses the C++ standard version if
available of any dual library, but you camn override the default choice.

> If I didn't want the
> switching behaviour I just wouldn't use the library. There might be a
> problem if other libraries are using CXXD and I (as a user of the other
> libraries) loose control of which implementation is being utilized.

That's why the override macros exist, so you can insist that a dual
library implementation use the single implementation you want. Please
read the doc to discover that. You don't "lose control".

Boost list run by bdawes at, gregod at, cpdaniel at, john at