virtual-by-default rant

F i L witte2008 at gmail.com
Sun Mar 18 06:54:18 PDT 2012


Manu wrote:
> I mean it can't possibly know the complete 'final' class 
> hierarchy, ie, the
> big picture. Anything anywhere could extend it. The codegen 
> must assume
> such.

I still don't understand why you think this. The compiler must 
understand the full hierarchy it's compiling, and like I said 
before, there are very distinct rules as to what should get 
virtualed across a lib boundary.


> Are you saying someone might accidentally override something 
> that's not
> virtual? That's what 'override' is for. If a method is final, 
> it is a
> compile error to override in any way, you either need to make 
> the base
> virtual, or explicitly 'override' on the spot if you want to do 
> that.

I was saying that I see how:

     class Base { // author: Bob
         void commonNamedMethod() {}
     }

     // ~~~~~

     class Foo : Base { // author: Steve
         // didn't look at base class, before writing:
         void commonNamedMethod() {}
         // therefor didn't realize he overwrote it
     }

is a valid concern of having things default to virtual. I just 
don't think it would happen often, but I've been known to be 
wrong.


> The virtual methods are the exception, not the common case.

I don't thinks it's so black and white, and that's why I like 
having the compiler make the optimization. I think marking 
(public) methods you know for sure who's functionality you don't 
want overwritten is often a smaller case than methods who's 
functionality could *potentially* be overwritten. By letting the 
compiler optimize un-overwritten methods, you're giving the Class 
users more freedom over the grey areas without sacrificing 
performances.

However, I also think the level of freedom is largely dependent 
on the situation. Given the fact that you write highly optimized 
and tightly controlled core game engine code, I can see why your 
perspective leans towards control.

Given this specialization unbalance, I think that both virtual 
and final should be available.


> Explicit virtual even gives a nice informative cue to
> the programmer just how they are supposed to work with/extend 
> something. You can clearly see what can/should to be extended.

This is a good argument. If nothing else, I think there should be 
a way for Class authors to specify (in a way code-completion can 
understand) a method attribute which marks a it as being designed 
to be overwritten.


> I sincerely fear finding myself false-virtual hunting on build 
> night until
> 2am trying to get the game to hold its frame rate (I already do 
> this in
> C++, but at least you can grep for and validate them!). Or 
> cutting content
> because we didn't take the time required to manually scan for 
> false
> virtuals that could have given us more frame time.

I think tool that maps hierarchy (showing override) would be best.
like: dmd -hierarchy"map.txt"


> You're welcome to it, but granted that, I have an additional 
> fear that
> someone with your opinion is capable of writing classes in libs 
> that I
> might really like to use, but can't, because they are a severe 
> performance
> hazard.

I would argue that any such performance critical libraries should 
be tightly "finalized" in the first place. I think you're 
assuming the compiler can't, in good faith, optimize out virtual 
functions. Whereas I'm assuming it can.



More information about the Digitalmars-d mailing list