Re: [Boost-users] Pointer Container Library changes in 1.66.0

Subject: Re: [Boost-users] Pointer Container Library changes in 1.66.0
From: Daniel James (dnljms_at_[hidden])
Date: 2018-04-05 17:56:05

On 5 April 2018 at 18:42, Nevin Liber <nevin_at_[hidden]> wrote:
> On Thu, Apr 5, 2018 at 12:35 PM, Daniel James via Boost-users
> <boost-users_at_[hidden]> wrote:
>>
>> On 5 April 2018 at 17:45, Nevin Liber <nevin_at_[hidden]> wrote:
>> > On Thu, Apr 5, 2018 at 11:25 AM, Daniel James via Boost-users
>> > <boost-users_at_[hidden]> wrote:
>> >>
>> >> On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users
>> >> <boost-users_at_[hidden]> wrote:
>> >> >
>> >> > It's the fact that one of the merged changes was to inherit privately
>> >> > from
>> >> > the clone_allocator which in turn forbids the use of final classes as
>> >> > clone_allocator types.
>> >>
>> >> Oh, that's something I haven't thought about. There are quite a few
>> >> places in boost where inheritance from generic types is used,
>> >> presumably they've all got the same problem. I'm not sure if there's a
>> >> good way to handle this.
>> >
>> >
>> > Can't you just wrap it and derive from the wrapper?
>> >
>> > For instance, I have a wrapper (which is a little overkill for this) at
>> > ebo_wrapper.h.  My version uses the traits in std, but Boost.TypeTraits
>> > has
>> > equivalents.
>>
>> boost::is_final doesn't work everywhere, and std::is_final is C++14,
>> so I don't think we've got wide enough support.
>
>
> Can't we assume either (a) users specialize it (as the documentation says
> to) or (b) more pessimistically assume all classes are final for C++11 or
> later compilers when BOOST_IS_FINAL is not defined?

I guess (a) is okay, but (b) could cause binary incompatibilities
(something I try to avoid, not sure about others).