Boost logo

Boost :

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


On 08/23/18 13:40, Glen Fernandes wrote:
>
> On Thursday, August 23, 2018, Andrey Semashev via Boost
> <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
>
> 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.
>
> Andrey, the macro is not intended to replace the type trait. Both exist
> today, both will continue to exist. Users who want to use BOOST_IS_FINAL
> over boost::is_final will continue to do so. Users who want to use
> boost::is_empty because of it's workarounds over BOOST_IS_EMPTY will
> continue to do so. The only thing that would change is where the
> definition of BOOST_IS_FINAL lives.

I gathered that you intended to use BOOST_IS_FINAL as a way to access a
compiler intrinsic, i.e. use it in place of the type trait.

> The TypeTraits intrinsic macros are public today and users are using
> them. They are also all just about compiler detection and mapping to the
> right intrinsic, nothing more. Them living in Config is not confusing to
> users, because Config is all about compiler specfic detection anyway.

I didn't find those macros documented. Specifically for BOOST_IS_FINAL,
it is mentioned as a *way to detect* whether `boost::is_final` gives the
actual result and not just `false`. The docs don't say that
BOOST_IS_FINAL is a way to access compiler intrinsics, so if someone is
using it this way, he is relying on implementation details.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk