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

On 2017-08-18 23:05, degski via Boost wrote:

On 18 August 2017 at 13:47, Vladimir Batov via Boost wrote:

...

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.

Aren't you doing something wrong (in your design) then? You called it: "standard allocator-usage pattern.". Standard is the key word here isn't it, that's what should be used IMHO.

It's not about "doing" but rather "not doing". :-) It is an important design decision. Namely, where the allocator deployment is to be declared. One choice is to follow pimpl's philosophy and to deploy it in the implementation, i.e. totally hide it from the user, i.e. the developer decides how his pimpl implementation uses memory. The other choice is the standard (external) allocator deployment, i.e. applying it to the proxy declaration, i.e. giving it to the user. The advantage of the first choice is the same as the main pimpl's advantage -- the developer decides to optimize or not memory usage, when and how. Seems attractive. The advantage of the second choice is that it is the standard allocator deployment with all the perks. Attractive no less. That appears to be a serious design decision with long-term impact and the potential of alienating some users (who are staunchly for one design or the other). Consequently, I was not implementing that hard bit as I personally do not use it. My idea was that, if impl_ptr gets over the "endorsement request" hurdle and gets to the review stage, then I'd bring that design problem to the list and we'd decide one way or the other. If impl_ptr does not get anywhere and is only used in my backyard, then I'll leave it as-is.