Re: Follow-up Pimpl question
On Tuesday, 22 October 2013 21:52:19 UTC+3, Rupert Swarbrick wrote:
=D6=F6 Tiib <ootiib@hot.ee> writes:
<snip naming>
There is better separation of concerns. Abstraction implements
external interface. Implementor implements internal implementation.
There are more dynamics. For example when object behind pointer to
interface is made then it can not change its type anymore in C++.
The implementor that is behind abstraction of pimpl however may be
is dynamically replaced, shared, cached, reused or copied-on-write etc.
by abstraction. It is not business of user of abstraction but
externally it may feel like type has changed entirely during life-time
of abstraction.
Ah, I hadn't thought about the copy-on-write use case. But how is that
different to doing it on one or more members of an abstract base class's
implementation? Presumably more data members actually means that you
have more fine-grained control!
Derived classes have one or more polymorphic members accessible from base=
abstract interface? It is even more complex.
Slight performance advantage of pimpl is that the virtual functions
are not needed. There may be virtual functions as implementor may be
polymorphic ... but those are not mandatory. So virtual functions
may be used when those improve performance, not when they describe
common interface.
That doesn't make much sense to me. Surely every public function in your
class has to look something like
void interface::function (int x)
{
pimpl->function (x);
}
Pimpl typically does not have exact same names in its interface:
void const* interface::address() const
{
return &pimpl_->data();
}
which... is a virtual function table, just manually written out.
If something does not make sense to you then measure. ;)
Compilers are quite happily removing such thin one liner forwarding
functions by inlining. Nothing like that is done with vtable.