Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2016-06-01 08:05:38

On 2016-06-01 20:40, Domagoj Saric wrote:
> 
> * +1 for 'standardizing' pimpling (and bringing it up yet again;)

Good.

> * -1 for 'breaking namespace usage' (forcing implementation in the
> global namespace) ...

I believe that's been addressed... From the user perspectives anyway. 
Your mileage may vary.

> * -1 for forcing heap usage...

This is incorrect. The proposed design is policy-based, i.e. 
configurable/customizeable. Indeed, I personally only implemented 
heap-based policies that I care about. Care to provide a stack-based 
policy based on your implementation? That already was one the requests 
on the thread.

> And no, allocators won't ('fully') do it. You still have extra
> indirection and even more code complexity (allocators which use stack
> in the current function? ugh...)...

I would not be so rush dismissing allocators. There must be reasons why 
we have them in the Standard.

> * -1 for the 'pointer/value semantics' 'kludge'

Not sure what you mean by that. Anyway, I'll provide some history. As 
you are aware that pimpl stands for "pointer to implementation". Stress 
is on "pointer". Kludge or not from the set-go very early 
implementations of the idiom had pointer-semantics. In fact, they *were* 
pointers (opaque pointers throughout, say, X Window System). Then, when 
we had a pimpl-related discussion on the list many moons ago "value 
semantics" were requested and been provided. Now it's implemented as a 
manager. If you do not need/like it, you simply do not use it. You 
provide your own stack-based manager (incidentally with value-semantics) 
and use it. Does it sound acceptable?

> IMO this is completely misplaced, I can't see it serving as anything
> else but replacing/wrapping the standard arrow/-> (smart)pointer
> syntax with the dot syntax. If the particular class objects are always
> to be heap allocated simply use them through a pointer...

I am under impression you've disposed of the pivotal pimpl property -- 
implementation hiding. Looking at your implementation seems to confirm 
that view... I could be wrong. If my understanding and reading of your 
code are correct, then, yes, indeed with no implementation-hiding goal 
all that code is "completely misplaced" and "serving as anything else 
but" and unnecessary. I agree.

> * -1 for paying for shared_ptr for inherently shared classes of objects
> Use boost::intrusive_ptr for those (in fact make the 'actual' factory
> function, that is implemented on the .cpp side, private and have it
> return a naked pointer, so that it can return it through a register
> across the ABI, and then wrap on the interface side in an inline
> member that returns a smart_ptr)...

You might be right and boost::intrusive_ptr is far superior to 
std::shared_ptr. I personally never liked the intrusiveness of 
boost::intrusive_ptr. And I suspect that that requirement of 
boost::intrusive_ptr won't sit well with at least some users as well.

As the intrusive_ptr docs state: "As a general rule, if it isn't obvious 
whether intrusive_ptr better fits your needs than shared_ptr, try a 
shared_ptr-based design first". And it is not obvious to me at the 
moment.

I believe shared_ptr is as efficient as boost::intrusive_ptr when 
created with make_shared or allocate_shared (used in the proposal). 
Well, apart from the 2-pointers' foot-print... which IMO is the proper 
way to go.