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