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.