Boost logo

Boost :

Subject: Re: [boost] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-03-06 06:27:09

On 2016-03-06 12: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
> (
> 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.

I don't mind having that in Boost (in fact, I welcome it) but these
tools are specific to functional domain, AFAIU. I think Boost.Phoenix
has something similar as well. Maybe, if there's a common ground in
these tools, they should all be unified and extracted to a new separate

Boost list run by bdawes at, gregod at, cpdaniel at, john at