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;)
> * -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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk