Re: [boost] Cxx dual library

Subject: Re: [boost] Cxx dual library
From: Michael Caisse (mcaisse-lists_at_[hidden])
Date: 2016-06-03 15:27:52

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.

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

-- 
Michael Caisse
Ciere Consulting
ciere.com