Re: [boost] Review Request: impl_ptr (pimpl)

Subject: Re: [boost] Review Request: impl_ptr (pimpl)
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2017-08-21 09:13:46

>> https://howardhinnant.github.io/stack_alloc.html
>> I think it is very elegant if one can switch to a stack-based version
>> without huge code-refactoring if the performance need arises (I am
>> paraphrasing your documentation).
> 
> Thank you for the link. Much appreciated. I'll most certainly read as it's what I've been scratching my head about for some time... Had a quick glance. I can be dead wrong but it does not seem (unfortunately) applicable to impl_ptr. It appears to be the standard allocator-usage pattern, i.e. I explicitly create an allocator (and memory arena) and then take from that arena. It's not applicable in the impl_ptr::onstack situation. Again, I'll have to read again.

I am not an expert either  :). I looked into allocators from the user-perspective so far, and I worked towards making my project, histogram, allocator aware. I like about allocators that they separate memory management from other semantics, like ownership. One can have a shared_ptr or a unique_ptr with memory allocated from a stack or pool, for example. Howard makes the case that there is no need for a special container like boost::small_vector

http://www.boost.org/doc/libs/master/doc/html/container/non_standard_containers.html

if one uses a stack-allocator with the standard vector. That sounds fantastic, so I thought it could also work here?

Howard originally had designed another allocator where the arena was internalised. That one would fit better with your policy, I think. It is a downside of Howards stack allocator, that one has to create a separate arena object on the stack before constructing the actual object that uses the memory in the area. I suppose that's what you mean by saying it conflicts with the onstack situation? 

I googled some more and found his answer on stackoverflow why the arena is separate

https://stackoverflow.com/questions/11648202/questions-about-hinnants-stack-allocator

and also the explanation here, lines 23 to 35:
https://src.chromium.org/viewvc/chrome/trunk/src/base/containers/stack_container.h?view=markup

I understand from these sources that allocator copies must be able to deallocate memory of each other, which effectively means they have to point to the same arena, hence the area must be external to have a life-time independent of the allocator.