Re: [boost] Pimpl Again?

On 28.5.2016. 7:41, Vladimir Batov wrote:
<...>
 > Thoughts? No pressure. I am easy either way. :-)

* +1 for 'standardizing' pimpling (and bringing it up yet again;)


* -1 for 'breaking namespace usage' (forcing implementation in the 
global namespace)
This is IMO not 'a matter of style', you could otherwise push it a 
little more and say that C++ is a 'specific style of C'...

There are several different ways to address this,
https://github.com/psiha/pimpl/tree/master/include/boost/pimpl:

1) auto_pimpl.hpp ('public'/interface side include), ln 85: impl() 
member function w/ C++14 return type deduction

2) auto_impl.hpp ('private'/impl side include), ln 48:
struct implementation "Interface -> implementation mapping metafunction"

So:
a) by default impl() 'asks' 'boost::pimpl::implementation<>' for the 
impl-type to which it needs to cast the this pointer
b) by default implementation::type maps to Interface::impl.
...and each of those steps can be customized/specialized...

So, by default, if you have a class my_interface, you would only need to 
include a forward declaration for impl in the interface:
class my_interface { public: class impl; }
and then implement it in the .cpp.

If that isn't satisfactory one can specialize:
- boost::pimpl::implementation (to 'point' to a different type)
   >or<
- boost::pimpl::*_object::impl() (not to use the default 
implementation<> metafunction)

This could, as always, be further refined 'by yet another layer of 
indirection', by using a free function for the 'Interface & -> Impl &' 
conversion (which could then simply overloaded in the user's namespace 
and have ADL kick in)...


Considering I'm always for giving more options (i.e. the opposite of the 
shared_ptr approach), and how differing opinions obviously still are WRT 
pimpling, I'd vote that at least the boost (if not the eventual std) 
pimpl version provides as many customization points as possible until 
usage patterns 'fall into place'...


* -1 for forcing heap usage
https://github.com/psiha/pimpl/blob/master/README.md
This is a complete C++14 rewrite of an old private pimpl framework which 
features a 'stack' or 'auto' (as in automatic storage) pimpl and as well 
as a heap based version. This is very recent undertaking, the heap 
version hasn't been ported at all, and the auto version doesn't yet 
handle the problematic use cases, inheritance and polymorphism (which 
are much more easily handled in the heap version)...

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...)...


* -1 for the 'pointer/value semantics' 'kludge'
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...


* -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)...


-- 
"What Huxley teaches is that in the age of advanced technology, 
spiritual devastation is more likely to come from an enemy with a 
smiling face than from one whose countenance exudes suspicion and hate."
Neil Postman