Re: [boost] [Boost-users] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core
On Saturday, March 5, 2016 10:50 PM, Steven Watanabe <watanabesj@gmail.com> 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.
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.
In Christ,
Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Le 06/03/2016 06:16, paul Fultz a écrit :
On Saturday, March 5, 2016 10:50 PM, Steven Watanabe <watanabesj@gmail.com> 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_c...
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
On Sunday, March 6, 2016 at 3:44:31 AM UTC-6, Vicente J. Botet Escriba wrote:
Le 06/03/2016 06:16, paul Fultz a écrit :
On Saturday, March 5, 2016 10:50 PM, Steven Watanabe <
watan...@gmail.com <javascript:>> 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_c...
That doesn't seem easily configurable by the user. I think I would prefer to make it configurable by the library and use Boost.Config for the default value.
participants (3)
-
paul Fultz -
Paul Fultz II
-
Vicente J. Botet Escriba