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 |
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 |
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 |
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 |
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 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. -- Nevin ":-)" Liber <mailto:[hidden email]> +1-847-691-1404 _______________________________________________ Boost-users mailing list [hidden email] https://lists.boost.org/mailman/listinfo.cgi/boost-users |
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 |
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: Nevin ":-)" Liber <mailto:[hidden email] _______________________________________________ Boost-users mailing list [hidden email] https://lists.boost.org/mailman/listinfo.cgi/boost-users |
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 |
In reply to this post by 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 |
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 |
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 |
Free forum by Nabble | Edit this page |