Pointer Container Library changes in 1.66.0

older
[log] Unable to use own severity...

Kevin Hardman

1 Feb 2018 1 Feb '18

12:57 p.m.

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 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

Attachments:

attachment.html (text/html — 676 bytes)

Show replies by date

Daniel James

22 Mar 22 Mar

4:45 p.m.

On 1 February 2018 at 12:57, Kevin Hardman via Boost-users 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

Thorsten Ottosen

5 Apr 5 Apr

3:11 p.m.

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 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

Daniel James

4:25 p.m.

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

Nevin Liber

4:45 p.m.

On Thu, Apr 5, 2018 at 11:25 AM, Daniel James via Boost-users < boost-users@lists.boost.org> wrote:

...

On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users 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 https://github.com/nliber/cool/blob/master/ebo_wrapper.h. My version uses the traits in std, but Boost.TypeTraits https://www.boost.org/doc/libs/1_66_0/libs/type_traits/doc/html/index.html has equivalents. -- Nevin ":-)" Liber > +1-847-691-1404

Daniel James

5:35 p.m.

On 5 April 2018 at 17:45, Nevin Liber wrote:

...

On Thu, Apr 5, 2018 at 11:25 AM, Daniel James via Boost-users wrote:

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

Nevin Liber

5:42 p.m.

On Thu, Apr 5, 2018 at 12:35 PM, Daniel James via Boost-users < boost-users@lists.boost.org> wrote:

...

On 5 April 2018 at 17:45, Nevin Liber wrote:

...
On Thu, Apr 5, 2018 at 11:25 AM, Daniel James via Boost-users wrote:

...
On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users 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? -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com +1-847-691-1404

Daniel James

5:56 p.m.

On 5 April 2018 at 18:42, Nevin Liber wrote:

...

On Thu, Apr 5, 2018 at 12:35 PM, Daniel James via Boost-users wrote:

...
On 5 April 2018 at 17:45, Nevin Liber wrote:

...
On Thu, Apr 5, 2018 at 11:25 AM, Daniel James via Boost-users wrote:

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

Thorsten Ottosen

6 Apr 6 Apr

8:12 a.m.

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 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

Daniel James

8:48 a.m.

On 6 April 2018 at 09:12, Thorsten Ottosen via Boost-users 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 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

Thorsten Ottosen

12:41 p.m.

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

2426

Age (days ago)

2490

Last active (days ago)

List overview

Download

10 comments

5 participants

participants (5)

Daniel James
Kevin Hardman
Nevin Liber
Nevin Liber
Thorsten Ottosen