Subject: Re: [boost] [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:59:55
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,
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk