Pointer Container Library changes in 1.66.0

[Boost - Users mailing list]

I am seeing changes in the Pointer Container Library that are preventing my existing application from compile. I see no notice of changes in the 1.66.0 release notes <http://www.boost.org/users/history/version_1_66_0.html>. Is there documentation on the changes and what is required to migrate existing users to the new library?

—kevin

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

On 1 February 2018 at 12:57, Kevin Hardman via Boost-users
<[hidden email]> wrote:
> I am seeing changes in the Pointer Container Library that are preventing my
> existing application from compile. I see no notice of changes in the 1.66.0
> release notes <http://www.boost.org/users/history/version_1_66_0.html>. Is
> there documentation on the changes and what is required to migrate existing
> users to the new library?

Sorry that no one answered this earlier. It looks like some old
changes from the develop branch were merged to master. It's not clear
which change caused your problem. Can you post the error message that
you're getting? And if possible, could you post a small test case that
replicates it?

thanks,

Daniel
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

Den 22-03-2018 kl. 17:45 skrev Daniel James via Boost-users:
> On 1 February 2018 at 12:57, Kevin Hardman via Boost-users
> <[hidden email]> wrote:
>> I am seeing changes in the Pointer Container Library that are preventing my
>> existing application from compile.


> Sorry that no one answered this earlier. It looks like some old
> changes from the develop branch were merged to master. It's not clear
> which change caused your problem. Can you post the error message that
> you're getting? And if possible, could you post a small test case that
> replicates it?

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.

-Thorsten
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users
<[hidden email]> 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.
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

On Thu, Apr 5, 2018 at 11:25 AM, Daniel James via Boost-users <[hidden email]> wrote:

On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users
<[hidden email]> 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-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

On 5 April 2018 at 17:45, Nevin Liber <[hidden email]> wrote:

> On Thu, Apr 5, 2018 at 11:25 AM, Daniel James via Boost-users
> <[hidden email]> wrote:
>>
>> On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users
>> <[hidden email]> 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.

(resent as accidentally sent off list)

This pull request will help:

https://github.com/boostorg/type_traits/pull/60

But still won't have full support.
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

On Thu, Apr 5, 2018 at 12:35 PM, Daniel James via Boost-users <[hidden email]> wrote:

On 5 April 2018 at 17:45, Nevin Liber <[hidden email]> wrote:
> On Thu, Apr 5, 2018 at 11:25 AM, Daniel James via Boost-users
> <[hidden email]> wrote:
>>
>> On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users
>> <[hidden email]> 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?

--

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

On 5 April 2018 at 18:42, Nevin Liber <[hidden email]> wrote:

> On Thu, Apr 5, 2018 at 12:35 PM, Daniel James via Boost-users
> <[hidden email]> wrote:
>>
>> On 5 April 2018 at 17:45, Nevin Liber <[hidden email]> wrote:
>> > On Thu, Apr 5, 2018 at 11:25 AM, Daniel James via Boost-users
>> > <[hidden email]> wrote:
>> >>
>> >> On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users
>> >> <[hidden email]> 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).
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

Den 05-04-2018 kl. 18:25 skrev Daniel James via Boost-users:

> On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users
> <[hidden email]> 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.

We always have compressed_pair, however ugly it is to use.

-Thorsten


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

On 6 April 2018 at 09:12, Thorsten Ottosen via Boost-users
<[hidden email]> wrote:

> Den 05-04-2018 kl. 18:25 skrev Daniel James via Boost-users:
>>
>> On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users
>> <[hidden email]> 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.
>
>
> We always have compressed_pair, however ugly it is to use.

compressed_pair has this problem as well. I created an issue:
https://github.com/boostorg/utility/issues/43
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

[Boost - Users mailing list]

Den 06-04-2018 kl. 10:48 skrev Daniel James via Boost-users:
> On 6 April 2018 at 09:12, Thorsten Ottosen via Boost-users

>> We always have compressed_pair, however ugly it is to use.
>
> compressed_pair has this problem as well. I created an issue:
> https://github.com/boostorg/utility/issues/43

Ah .. yes, I guess Keven needs to make his clone_allocator non-final for
now then. Should be easy enough.

-T

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users