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.