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

Subject: Re: [boost] Review Request: impl_ptr (pimpl)
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2017-08-22 00:38:00

On 2017-08-21 19:13, Hans Dembinski wrote:
>>> 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.

Thank you for the input and the links... and the nice 
allocator-usage-related description. Much appreciated. And, yes, your 
hunch that, if allocators work with std::vector, they should work with 
impl_ptr is correct (with caveats related to different std::vector and 
impl_ptr deployments patterns). I went down that path and introduced 
allocators... impl_ptr::onstack included... internally. That seemed 
easier to maintain and to use.