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:53:55

On 08/23/18 05:14, Gavin Lambert via Boost wrote:
> On 23/08/2018 13:31, Glen Fernandes wrote:
>> One thing about this suggestion: If Boost.Config was to provide macros
>> that tell users whether Boost.TypeTraits' boost::is_final<T>::value is
>> emulated or the real deal, then the compiler detection logic currently
>> in Boost.TypeTraits for detecting __is_final would already have to be
>> duplicated in Boost.Config. That does not sound like a great idea.
>>
>> Right now TypeTraits provides both, which is better. i.e. It provides
>> boost::is_final<T>::value and BOOST_IS_FINAL(T). The former uses the
>> latter if it is defined, or is always false if not defined.
>>
>> If BOOST_IS_FINAL(T) and all its compiler detection logic lives in
>> TypeTraits, then that all that compiler detection logic should not be
>> duplicated in Config to provide a BOOST_HAS_IS_FINAL_INTRINSIC or
>> similar feature detection macro.
> 
> 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?

I suspect, this would complicate Boost.TypeTraits maintenance, although 
I might be mistaken. Boost.TypeTraits would still have to check the 
compilers to see which flavor of intrinsics to use on different 
compilers or whar workarounds for compiler quirks are required. This 
means duplication between Boost.Config and Boost.TypeTraits.

Also, the sole user of these macros would be Boost.TypeTraits (I assume, 
noone wants to duplicate that detection logic yet again), so I don't see 
much value in this division.