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

newer
Re: [Boost-users] [boost]...

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

older
Visual Studio C++ and Boost...

Vicente J. Botet Escriba

6 Mar 2016 6 Mar '16

9:59 a.m.

Le 06/03/2016 09:59, Andrey Semashev a écrit :

...

On 2016-03-06 05:21, Vicente J. Botet Escriba wrote:

...
Others could be considered also as function.hpp, lambda.hpp and lift.hpp, as the macros are there to workaround some missing language features, but those are much more specialized (Boost.Core?)

I don't think Boost.Core is the right place for them as this library is for small generally useful components used by many libraries. The components you pointed out seem too specialized to me, and Boost.Fit looks like the right place for them.

|Andrey, I was thinking in Boost.Core as these are language-like emulation features, like e.g. addressof, enable_if, explicit_operator_bool, ignorunused, no_exception_support, noncopyanble, scoped_enum, typeinfo. IIUC, BOOST_FIT_STATIC_FUNCTION try to fix a standard Core issue (pending issue 2104 in CWG) identified by Eric Nibler, with the a solution based on proposal's Eric (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html). The library has also a macro BOOST_FIT_DECLARE_STATIC_VAR to do it for any data variable. I would like something that solves this problem in Boost. BOOST_FIT_STATIC_LAMBDA try to covers the C++17 feature constexpr lambdas. I suspect that Boost.Hana should have something like that. Louis, could you tell us how do you manage with these issues? IMO, The fiw of those issues is independent from a functional utilities library, even if Fit can not work without them.|| This is way I believe that it should be extracted and Boost.Core seems the good place to me. Best, Vicente |

Attachments:

attachment.html (text/html — 2.4 KB)

Show replies by date

Louis Dionne

6 Mar 6 Mar

2:29 p.m.

New subject: [boost] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core

...

On Mar 6, 2016, at 04:59, Vicente J. Botet Escriba wrote:

Le 06/03/2016 09:59, Andrey Semashev a écrit :

...
On 2016-03-06 05:21, Vicente J. Botet Escriba wrote:

...
Others could be considered also as function.hpp, lambda.hpp and lift.hpp, as the macros are there to workaround some missing language features, but those are much more specialized (Boost.Core?)

I don't think Boost.Core is the right place for them as this library is for small generally useful components used by many libraries. The components you pointed out seem too specialized to me, and Boost.Fit looks like the right place for them.

Andrey, I was thinking in Boost.Core as these are language-like emulation features, like e.g. addressof, enable_if, explicit_operator_bool, ignorunused, no_exception_support, noncopyanble, scoped_enum, typeinfo.

IIUC, BOOST_FIT_STATIC_FUNCTION try to fix a standard Core issue (pending issue 2104 in CWG) identified by Eric Nibler, with the a solution based on proposal's Eric (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html). The library has also a macro BOOST_FIT_DECLARE_STATIC_VAR to do it for any data variable. I would like something that solves this problem in Boost.

BOOST_FIT_STATIC_LAMBDA try to covers the C++17 feature constexpr lambdas.

I suspect that Boost.Hana should have something like that. Louis, could you tell us how do you manage with these issues?

I don’t manage these issues. Hana uses only hand-written function objects that can be marked constexpr, and lambdas are completely excluded from the codebase. There’s no way to properly workaround the limitations of constexpr lambdas, since the lambda’s operator() won’t be constexpr even with BOOST_FIT_STATIC_LAMBDA. Regards, Louis

Vicente J. Botet Escriba

3:21 p.m.

New subject: [boost] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core

Le 06/03/2016 15:29, Louis Dionne a écrit :

...

...
On Mar 6, 2016, at 04:59, Vicente J. Botet Escriba wrote:

Le 06/03/2016 09:59, Andrey Semashev a écrit :

...
On 2016-03-06 05:21, Vicente J. Botet Escriba wrote:

...
Others could be considered also as function.hpp, lambda.hpp and lift.hpp, as the macros are there to workaround some missing language features, but those are much more specialized (Boost.Core?) I don't think Boost.Core is the right place for them as this library is for small generally useful components used by many libraries. The components you pointed out seem too specialized to me, and Boost.Fit looks like the right place for them.

Andrey, I was thinking in Boost.Core as these are language-like emulation features, like e.g. addressof, enable_if, explicit_operator_bool, ignorunused, no_exception_support, noncopyanble, scoped_enum, typeinfo.

IIUC, BOOST_FIT_STATIC_FUNCTION try to fix a standard Core issue (pending issue 2104 in CWG) identified by Eric Nibler, with the a solution based on proposal's Eric (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html). The library has also a macro BOOST_FIT_DECLARE_STATIC_VAR to do it for any data variable. I would like something that solves this problem in Boost.

BOOST_FIT_STATIC_LAMBDA try to covers the C++17 feature constexpr lambdas.

I suspect that Boost.Hana should have something like that. Louis, could you tell us how do you manage with these issues? I don’t manage these issues. Hana uses only hand-written function objects that can be marked constexpr, and lambdas are completely excluded from the codebase. There’s no way to properly workaround the limitations of constexpr lambdas, since the lambda’s operator() won’t be constexpr even with BOOST_FIT_STATIC_LAMBDA.

Sorry it was me that did the association of BOOST_FIT_STATIC_LAMBDA to C++17 constexpr lambdas.

...

"The |BOOST_FIT_STATIC_LAMBDA| macro allows initializing non-capturing lambdas at compile-time in a |constexpr| expression."

Nevertheless we get the ability to declare them at the namespace level, which is already a good step, or do you consider that this is not useful? Paul, if Louis is right, I believe that the documentation should state clearly that even if the resulting function can be assigned to a constexpr variable the user can not call it at compile-time, and even if this is obvious for the experts. Vicente

Paul Fultz II

7 Mar 7 Mar

4:48 a.m.

New subject: [boost] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core

On Sunday, March 6, 2016 at 8:30:19 AM UTC-6, Louis Dionne wrote:

...

...
On Mar 6, 2016, at 04:59, Vicente J. Botet Escriba javascript:> wrote:

...
On 2016-03-06 05:21, Vicente J. Botet Escriba wrote:

...
Others could be considered also as function.hpp, lambda.hpp and lift.hpp, as the macros are there to workaround some missing language features, but those are much more specialized (Boost.Core?)

I don't think Boost.Core is the right place for them as this library is for small generally useful components used by many libraries. The components you pointed out seem too specialized to me, and Boost.Fit looks

Le 06/03/2016 09:59, Andrey Semashev a écrit : like the right place for them.

...
Andrey, I was thinking in Boost.Core as these are language-like emulation features, like e.g. addressof, enable_if, explicit_operator_bool, ignorunused, no_exception_support, noncopyanble, scoped_enum, typeinfo.

IIUC, BOOST_FIT_STATIC_FUNCTION try to fix a standard Core issue (pending issue 2104 in CWG) identified by Eric Nibler, with the a solution based on proposal's Eric ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4381.html). The library has also a macro BOOST_FIT_DECLARE_STATIC_VAR to do it for any data variable. I would like something that solves this problem in Boost.

BOOST_FIT_STATIC_LAMBDA try to covers the C++17 feature constexpr lambdas.

I suspect that Boost.Hana should have something like that. Louis, could you tell us how do you manage with these issues?

I don’t manage these issues. Hana uses only hand-written function objects that can be marked constexpr, and lambdas are completely excluded from the codebase. There’s no way to properly workaround the limitations of constexpr lambdas, since the lambda’s operator() won’t be constexpr even with BOOST_FIT_STATIC_LAMBDA.

That is correct. It only allows for constexpr initialization of the lambda, which is why I call it `STATIC_LAMBDA` instead of `CONSTEXPR_LAMBDA`. I probably should add some more documentation to make it clearer. Also note, that the Fit library only uses functions objects as well. The only place that lambdas are used is for the lift operator.

3170

Age (days ago)

3171

Last active (days ago)

List overview

Download

3 comments

3 participants

participants (3)

Louis Dionne
Paul Fultz II
Vicente J. Botet Escriba