Re: [boost] [Boost-users] [Fit]Â formal review - should we propose some parts to Boost.Config/Boost.Core

Subject: Re: [boost] [Boost-users] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-03-06 04:43:32

Le 06/03/2016 06:16, paul Fultz a écrit :
>
>
>
>
>> On Saturday, March 5, 2016 10:50 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>>> AMDG
>> On 03/05/2016 07:21 PM, Vicente J. Botet Escriba wrote:
>>>   I want to start a new sub-thread about some of the concerns of Steven
>>>   Watanabe about whether some of the contents of this library fits better
>>>   in Boost.Config. In particular the file boost/fit/returns.hpp.
>>>
>> When I mentioned Boost.Config, I was talking about
>> things like
>>
>> #ifndef BOOST_FIT_NO_EXPRESSION_SFINAE
>> #ifdef _MSC_VER
>> #define BOOST_FIT_NO_EXPRESSION_SFINAE 1
>> #else
>> #define BOOST_FIT_NO_EXPRESSION_SFINAE 0
>> #endif
>> #endif
> This is can be configurable, whereas Boost.Config it is not.
I'm not sure this is true.
http://www.boost.org/doc/libs/1_60_0/libs/config/doc/html/index.html#boost_config.configuring_boost_for_your_platform.user_settable_options

>
>> or
>>
>> #ifndef BOOST_FIT_HAS_TEMPLATE_ALIAS
>> #if (defined(__GNUC__) && !defined (__clang__) && __GNUC__ == 4
>> &&
>> __GNUC_MINOR__ < 7)
>> #define BOOST_FIT_HAS_TEMPLATE_ALIAS 0
>> #else
>> #define BOOST_FIT_HAS_TEMPLATE_ALIAS 1
>> #endif
>> #endif
>>
> This could be replaced with Boost.Config, however, I have ran into problems before with template aliases on gcc 4.7, so I wanted to make this configurable as well, although it could fallback onto Boost.Config right now.
Detection and configuration are two different things. There are two 
libraries that do detection,  Boost.Config or Boost.Predef. If for some 
reason you want to configure your library for a specific point this must 
be different from the detection of whether a feature is available or 
not. Of course the user could only disable an available feature, not the 
opposite.
Paul you could use either Boost.Config or Boost.Predef for the detection 
part.  I know less Boost.Predef.

Anything that can be configured must be documented in your library.
Both libraries have also a way to configure but in this case you 
configure the whole Boost library that use these libraries.

It is worth noting that the Fit library don't depend today on any Boost 
library and that Paul has reinvented a lot of things Boost provides 
already.
I can understand this approach for a library independent of Boost, but 
when the library in integrated in Boost, it should use other ad-hoc 
Boost libraries.

Steven, this was my fault. I should have done a deeper code inspection 
before the review to request  the adaptation. Apologies to all the 
reviewers for not have been done that.

I believe that we can identify the parts that need to be reworked to 
adapt its style to the Boost. Boost Hana, was also almost in the same 
case and had also its own standard type traits to avoid dependencies. 
Fit is a C++11 library that want to support compilers that are not too 
C++11 compliant. I would prefer that the library was a C++14 library 
that supports only the last compilers, Tis will make the code more 
readable, but it is up to Paul to decide what he wants to support.

Best,
Vicente