20.09.2013 12:45, Ali Çehreli пишет:
On 09/19/2013 10:31 PM, Alexandr Druzhinin wrote:
> if I use protected instead of private in interface like:
private member functions are non-virtual.
But I just use code example from TDPL russian edition. And TDPL says
clearly that (un)transmogrify() are private and CardboardBox _maynot_
make (un)transmogrify() non-private - this is highlighted as compiler
support of NVI idiom. Is it wrong example, I guess?
> interface Transmogrifier
> {
> final void thereAndBack()
> {
> transmogrify();
> untransmogrify();
> }
>
> protected:
> void transmogrify();
> void untransmogrify();
> }
If they were non-virtual (i.e. private), the calls to transmogrify() and
untransmogrify() from thereAndBack() would be bound to
Transmogrifier.transmogrify and Transmogrifier.untransmogrify at compile
time. That happens and the linker cannot find their definitions.
I see. Thanks, I understand it now better
> class CardboardBox: Transmogrifier
> {
> override protected void transmogrify() { }
> override void untransmogrify() {}
> }
> it compiles, but why does compiler permit making untransmogrify() be
> public?
It is up to CardboardBox to decide whether untransmogrify() is public or
not. Note that untransmogrify() is still protected when objects are used
through the Transmogrifier interface. However, when an object is known
to be a CardboardBox so that it is being used through the CardboardBox
interface, it is not bound to be a Transmogrifier at that point. Yes,
CardboardBox inherits from Transmogrifier but it is CardboardBox's
interface that is being used at that point so it decides.
Thanks again. So there is no compiler support for NVI idiom? Because if
CardboardBox may define its own (un)transmogrify() - TDPL says it
possible only if (un)transmogrify() have other signatures.
> How can I prohibit this? May be it just unrealized yet?
You cannot prohibit from Transmogrifier.
Ali
Unfortunately I tried to use NVI for it namely.
