Subject: Re: [boost] [Modularization] new Memory module
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-09 12:56:26
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
>> In any case, if reusable, I would make a new library (with
>> documentation and test cases), not only a new git module.
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk