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 02:27:54

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.

> That seems like a more appropriate division of responsibilities to me.

Agreed. I prefer as much compiler-detection to reside in Config where
I feel it has the best maintenance.

Glen