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

Subject: Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-08-23 09:58:38

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.