Pointer Container Library changes in 1.66.0
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
On 1 February 2018 at 12:57, Kevin Hardman via Boost-users <boost-users@lists.boost.org> 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
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 <boost-users@lists.boost.org> 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
On 5 April 2018 at 16:11, Thorsten Ottosen via Boost-users <boost-users@lists.boost.org> 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.
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 <boost-users@lists.boost.org> 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 <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>> +1-847-691-1404
On 5 April 2018 at 17:45, Nevin Liber <nevin@cplusplusguy.com> wrote:
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 <boost-users@lists.boost.org> 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.
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 <nevin@cplusplusguy.com> wrote:
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 <boost-users@lists.boost.org> 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
On 5 April 2018 at 18:42, Nevin Liber <nevin@eviloverlord.com> wrote:
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 <nevin@cplusplusguy.com> wrote:
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 <boost-users@lists.boost.org> 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).
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 <boost-users@lists.boost.org> 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
On 6 April 2018 at 09:12, Thorsten Ottosen via Boost-users <boost-users@lists.boost.org> 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 <boost-users@lists.boost.org> 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
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
participants (5)
-
Daniel James -
Kevin Hardman -
Nevin Liber -
Nevin Liber -
Thorsten Ottosen