Boost logo

Boost :

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:
>>> 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
> 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
> and also the explanation here, lines 23 to 35:
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at