Boost logo

Boost :

Subject: Re: [boost] Pimpl Again?
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2016-06-01 06:40:26


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<Interface>::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<my_class> (to 'point' to a different type)
>or<
- boost::pimpl::*_object<my_class>::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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk