On 02/14/2012 01:28 AM, Jonathan M Davis wrote:
On Tuesday, February 14, 2012 00:36:31 Timon Gehr wrote:
On 02/14/2012 12:26 AM, Jonathan M Davis wrote:
On Tuesday, February 14, 2012 00:15:40 Martin Nowak wrote:
Can you elaborate on what issues you see with NVI. After all it's only
the final public
method that needs to call the virtual private methods.
As I explain in that bug report, NVI can be acheived with protected
rather than private. So, we can do NVI now with private being
non-virtual. However, if we make private virtual, then the compiler can
no longer inline private functions in classes unless they're marked as
final. That's a performance hit to pretty much every class ever
written.
Yes, the conscientious programmer will mark their classes' private
functions final unless they intend to use them for NVI, but the
_default_ is then inefficient for little to no gain. All you gain is
the ability to do NVI with private instead of protected, and that is
not even vaguely worth the performance hit to almost every D class ever
IMHO.
- Jonathan M Davis
Virtual private does not allow for cross-module NVI, so what would be
the point anyway?
Why wouldn't it? The whole point of NVI is that you override it but don't call
it - the base class does that. So, the derived class could override the
private function but couldn't call it. It _is_ a bit weird though, all the
same.
It would break information hiding. A private method declared in a
different module is not supposed to be visible (hopefully will get
fixed), let alone overrideable.
Regardless, I'm against making private virtual because of the needless
performance hit.
There are no performance implications because the compiler has the whole
module ready to analyse. Therefore it can de-virtualise any calls to
private members that are never overridden. A trivial addition to the
class layout could furthermore allow the compiler to remove the vtable
entry for such a member function entirely (essentially, virtual private
members would get negative vtable offsets). I actually think that should
be implemented in order to get a potential TDPL error off the table.
