Re: [boost] [type_traits][core] modularisation and moving stuff about (again)

Subject: Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2018-08-23 10:40:10

On Thursday, August 23, 2018, Andrey Semashev via Boost <
boost_at_[hidden]> wrote:

> On 08/23/18 05:27, Glen Fernandes via Boost wrote:
>
>> On Wed, Aug 22, 2018 at 10:14 PM Gavin Lambert wrote:
>>
>>> What if Boost.Config contained all the compiler detection logic to
>>> define BOOST_HAS_IS_FINAL_INTRINSIC or not, and then Boost.TypeTraits
>>> had no detection and simply used BOOST_HAS_IS_FINAL_INTRINSIC to then
>>> define BOOST_IS_FINAL and boost::is_final<T> appropriately?
>>>
>>
>> Boost.Config simply providing BOOST_HAS_IS_FINAL_INTRINSIC which is
>> defined or not defined would mean Boost.TypeTraits would still need to
>> do the compiler detection logic to map its BOOST_IS_FINAL(T) to the
>> appropriate compiler intrinsic. e.g. For Sun it's
>> __oracle_is_final(T), for most others it's __is_final(T), for DMC it's
>> (__typeinfo(T) & 0x1000).
>>
>> Ultimately, it is not so far from what I proposed to John and created
>> pull requests for. Except instead of a macro named
>> "BOOST_HAS_IS_FINAL_INTRINSIC" in Config which is defined or
>> not-defined, the macro in Config is named "BOOST_IS_FINAL(T)" which is
>> defined to the appropriate intrinsic, or not defined at all.
>>
>> TypeTraits will still provide boost::is_final which uses
>> BOOST_IS_FINAL if defined, or is otherwise false. Except now
>> BOOST_IS_FINAL lives in Config, and all the compiler-detection logic
>> lives solely in Config.
>>
>
> What if the compiler intrinsic doesn't work in some cases?
> Boost.TypeTraits apply workarounds for such cases, so that the official
> trait works as intended. These workarounds might be impossible or expensive
> to do within a macro.

Andrey, the macro is not intended to replace the type trait. Both exist
today, both will continue to exist. Users who want to use BOOST_IS_FINAL
over boost::is_final will continue to do so. Users who want to use
boost::is_empty because of it's workarounds over BOOST_IS_EMPTY will
continue to do so. The only thing that would change is where the definition
of BOOST_IS_FINAL lives.

The TypeTraits intrinsic macros are public today and users are using them.
They are also all just about compiler detection and mapping to the right
intrinsic, nothing more. Them living in Config is not confusing to users,
because Config is all about compiler specfic detection anyway.

Glen