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