[Issue 4542] [tdpl] TDPL NVI example results in linker error

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4542



--- Comment #12 from Jonathan M Davis <jmdavisProg at gmx.com> 2011-09-08 20:40:36 PDT ---
The idea is to have a public, non-virtual function which does something before
and/or after calling a private virtual function. That way, you can guarantee
that certain things happen before or after the call to the private function.
However IIRC, you can't actually make the private function non-callable. I
forget what the details are. It was discussed in the newsgroup a while back,
and Steven Schveighoffer was able to show that using private instead of public
doesn't really buy you much in the way of protection - and the idiom works just
fine when you use protected instead of private. It just means that there's no
protection whatsoever against a derived class calling the virtual function
directly. So, it's by convention at that point, but since you could get around
it with private anyway (I don't remember exactly how at the moment,
unfortunately), it private doesn't actually give you that guarantee anyway.

So, NVI can be done with protected just fine. It might not be quite as nice
that way, but it works. On the other hand, making private virtual will result
in a systematic degredation in the performance of D programs in general. It can
be overcome with final, but it mean that the default is worse performance.

So, I really don't see much benefit in making private virtual. Protected will
give you the main benefits of NVI just fine, whereas making private virtual
gives you the slight benefit of increased cleanness in the use of NVI in some
programs at the cost of performance in pretty much all programs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------