Slow performance compared to C++, ideas?

Jonathan M Davis jmdavisProg at gmx.com
Thu Jun 6 17:13:12 PDT 2013


On Thursday, June 06, 2013 16:48:32 Walter Bright wrote:
> On 6/6/2013 3:12 PM, Jonathan M Davis wrote:
> > On Thursday, June 06, 2013 14:57:00 Walter Bright wrote:
> >> On 6/6/2013 2:23 PM, Andrei Alexandrescu wrote:
> >>> (The tool I'm envisioning
> >>> would add final annotations or prompt the user to add them.)
> >> 
> >> Sorry, that's never going to fly.
> > 
> > It could tell the programmer which functions it _thinks_ don't need to be
> > virtual, but it can't be 100% correct. So, it would effectively be a
> > lint-like tool targeting possible devirtualization opportunities. It
> > would actually be potentially useful regardless of whether virtual or
> > non-virtual is the default, since programmers may have needlessly marked
> > functions as virtual. But if it's a question of whether it's a good
> > solution for optimizing away virtuality instead of making functions
> > non-virtual, then I don't think that it would fly - not if optimization
> > is a prime concern. It would just be a nice helper tool for static
> > analysis which could give you suggestions on things you might be able to
> > improve in your program.
> 
> I know. But people are never going to use that tool.

Some would, but I completely agree that it wouldn't be used enough to be 
viable as a real solution for making functions non-virtual.

> I wouldn't have changed my mind if it were possible for the compiler to
> auto-finalize methods.

Yeah, if the compiler could figure it all out, that would be great, and this 
might not be necessary, but unfortunately, it clearly can't -t hough even if 
it could, there's definitely some value in the programmer being explicit about 
what is and isn't overridden. Taken to the extreme, that would probably 
require that every single member function be marked with either virtual, 
override, or final so that the programmer has to explicitly choose in each case 
what a function is supposed to be doing in terms of virtuality, but that's 
likely overkill and would break too much code at this point even if it were 
ultimately a good idea. As it stands, we can simply say that introducing 
functions must be marked with virtual and that functions marked with override 
must override a function which is marked with either virtual or override, and 
all people will have to do is mark the introducing functions with virtual. 
That'll certainly break some code, but considering how big a change it is, it 
affects a suprisingly small portion of the code.

- Jonathan M Davis


More information about the Digitalmars-d mailing list