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