[poly_collection] Boost.PolyCollection release version ready

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[poly_collection] Boost.PolyCollection release version ready

Boost - Users mailing list

Hello,

For those who are following the development of this lib, I'd like to announce that the
release version of Boost.PolyCollection for Boost 1.65 is already committed to the master
branch of Boost.

Much of the to-do list prepared by Ion at the end of the review has been implemented. The
main features left as roadmap are listed at:

http://www.boost.org/doc/libs/master/doc/html/poly_collection/future_work.html

As for the improvements already included, let me comment on what I feel are the most
important:

* The implementation has been refactored to avoid internal virtual calls at places where
the type of the segment involved is known at compile time. Also, segment lookup (the
process to get to the segment for U from typeid(U)) has been greatly sped up by means
of a std::type_info* cache. These two improvements result in a combined reduction of
around 25-30% in insertion times. There's an API breaking change though: no longer
is std::type_index used and const std::type_info &'s have to be directly provided
instead --this is likely to go unnoticed by those of you already using the lib.
* Polymorphic collections now satisfy standard requirements on allocator use as stated
in [container.requirements.general]/3 (or, more precisely, the natural interpretation for
polymorhpic containers of this clause). This is explicitly described in the reference. As a
result, polymorphic collections can now use std::scoped_allocator_adaptor without any
problem.
* Added segment(typeid(U))/segment<U>() convenience funtions returning a range
object over the selected segment. This allows us to write:

  for(const auto& x:c.segment(typeid(warrior))){
    ...
  }

* Collection-level max_size() and capacity() have been removed as I didn't seem to find
sensible semantics for them. Segment-level max_size() and capacity() are kept, of course.
* Hopefully the tutorial section on boost::function_collection is a bit clearer now.


The library works OK for MSVC>=14.0,GCC>=5.0,Clang>=3.7. Unfortunately, Intel fails
for test_algorithm:

https://lists.boost.org/Archives/boost/2017/06/236016.php

If someone's interested in helping fix that, please step up.

Thank you,

Joaquín M López Muñoz


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [poly_collection] Boost.PolyCollection release version ready

Boost - Users mailing list

* The implementation has been refactored to avoid internal virtual calls at places where
the type of the segment involved is known at compile time. Also, segment lookup (the
process to get to the segment for U from typeid(U)) has been greatly sped up by means
of a std::type_info* cache. These two improvements result in a combined reduction of
around 25-30% in insertion times. There's an API breaking change though: no longer
is std::type_index used and const std::type_info &'s have to be directly provided
instead --this is likely to go unnoticed by those of you already using the lib.

Was any more consideration given to using Boost.TypeIndex so that the library will work on compilers with rtti disabled? Or was that dismissed? I can't find where that thought ended up amongst all of the discussion.
 
-- chris

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [poly_collection] Boost.PolyCollection release version ready

Boost - Users mailing list

Em 28 jun 2017, às 0:31, Chris Glover <[hidden email]> escreveu:

[...]

Was any more consideration given to using Boost.TypeIndex so that the library will work on compilers with rtti disabled? Or was that dismissed? I can't find where that thought ended up amongst all of the discussion.


Joaquín M López Muñoz

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [poly_collection] Boost.PolyCollection release version ready

Boost - Users mailing list


On Tue, 27 Jun 2017 at 18:40 Joaquín M López Muñoz via Boost-users <[hidden email]> wrote:

Em 28 jun 2017, às 0:31, Chris Glover <[hidden email]> escreveu:

[...]

Was any more consideration given to using Boost.TypeIndex so that the library will work on compilers with rtti disabled? Or was that dismissed? I can't find where that thought ended up amongst all of the discussion.

 
Thank you.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [poly_collection] Boost.PolyCollection release version ready

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On 27/06/2017 23:57, Joaquin M López Muñoz via Boost-users wrote:
> Hello,
>
> For those who are following the development of this lib, I'd like to
> announce that the
> release version of Boost.PolyCollection for Boost 1.65 is already
> committed to the master
> branch of Boost.

Awesome Joaquín. Great addition for Boost 1.65 and performance
improvements are really good news.

Best,

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