Subject: Re: [boost] [config][type_traits] Support for final keyword in Boost?
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2014-08-16 09:34:39
On 16/08/2014 04:59 a.m., John Maddock wrote:
> I have a couple of pull requests to add support for the final keyword in
> Boost.Config and an is_final trait to type traits, so my questions are:
> 1) Are these generally useful?
> 2) Do we need BOOST_NO_CXX11_FINAL_CLASS and
> BOOST_NO_CXX11_FINAL_OVERRIDE or will a single BOOST_NO_CXX11_FINAL do?
> 3) The trait appears to be unimplementable via SFINAE (anyone care to
> prove me wrong?) which means it's only usable on GCC and lookalikes
> which have an __is_final intrinsic. Should we still add this to Boost
> or is the answer "use GCC's native features" given that a Boost version
> effectively adds nothing?
For completeness, let me state my motivation for those pull request. I'm
doing some work on Fusion sequences, and I want to apply the Empty Base
Optimization. Since C++11, this optimization has to be restricted to non
final classes, so the usual predicate is `std::is_empty<T>::value &&
!std::is_final<T>::value`. I believe this is the entire motivation
behind the addition of the `is_final` trait to the standard. I don't yet
know if those Fusion changes will end upstream, but it's likely that
other libraries doing EBO will want to restrict it to non-final classes.
By adding the corresponding trait, the user still has a chance to
specialize it for its own final types if the compiler can't detect that.
Note that MSVC will sooner or later have to implement `std::is_final`,
so "use GCC's native features" does not sound compelling.
-- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk