I forget to sent this message to the boost ML. Le 09/06/14 15:18, Vicente J. Botet Escriba a écrit :

Le 09/06/14 12:17, Ion Gaztañaga a écrit :

...

El 09/06/2014 10:11, Vicente J. Botet Escriba escribió:

...

Le 04/06/14 13:27, Vicente J. Botet Escriba a écrit :

...

|What about creating a Memory module containing| most of the things the standard defines in <memory> except maybe what is already in SmartPptr, e.g.

||* boost/interprocess/allocators/*|| |* boost/intrusive/pointer_traits.hpp | Any comments on this new module? Ion?

Thanks for the ping, I'm not closely following modularization threads.

Interprocess allocators are only usable by Interprocess users, I don't think they should be outside.

Sorry, I wanted to say container|

|| |||

...

intrusive::pointer_traits is usable from other libraries. Container uses it extensively, but Container heavily depends on Intrusive. I don't know if other libraries use it.

Boost.Thread uses allocators for future<T>.

...

We also have a portable allocator_traits implementation in Boost.Container that might be reusable by other boost containers. We need to see real use cases to see if this class makes sense in Boost.Memory or its place should be Container.

I'm for Memory as it is in the standard. See my use case for future<T>

...

For Boost 1.56 we'll have new allocators in Boost.Container, and those take advantage of Boost.Container internals to offer reallocation, burst allocation, etc. They could be usable by other Boost containers, but they are still experimental and unless there is a strong need for that, I would not move them to a new module now.

pointer_traits offers extensions not found in std::pointer_traits (like pointer casting). We need to to carefully think about this (Boost.Intrusive needs to make some conversions not covered by std::pointer_traits).

In any case, if reusable, I would make a new library (with documentation and test cases), not only a new git module.

Agreed.

...

So my opinion is: Don't move interprocess allocators, let's see if a strong need arises for a common pointer_traits/allocator_traits and we'll think about solutions.

We don't move nothing we can not do either because we are the owners or because these are libraries managed by the community maintenance team.

Please, take the time you need about this new module/library that could contain things similar to the ones found in <memory> except the smart pointer part.

Best, Vicente