virtual-by-default rant

Manu turkeyman at gmail.com
Sat Mar 24 03:56:09 PDT 2012


On 23 March 2012 21:11, Adam D. Ruppe <destructionator at gmail.com> wrote:

> Something that *might* help is to do unit tests. Yeah,
> that's kinda ass, but it would catch a stray virtual early.
>

They're not necessarily 'stray' virtuals, they're inappropriate ones
There's a time and place for virtuals, but there's many more times and
places they shouldn't be :)
It's nice to be able to skim a class and see 'virtual' written clearly all
over it to gather some basic performance/usage information about the class.
The visual cue is important, and the ability to grep for them.

Rememer that virtuals are

Do a unit test that does a traits check for virtuals:
>
> http://dlang.org/traits.html#**getVirtualFunctions<http://dlang.org/traits.html#getVirtualFunctions>
>
> if the name isn't on a list of approved virtuals,
> static assert fail.
>

I've said this all before, but I'll repeat my general reasoning on the
issue. My objection to virtual-by-default, but, acknowledging that can't be
changed, insistence on a virtual keyword is this. (uh oh, manu-rant alert)
:P

The top most compelling reason for switching from an extremely mature,
efficient, reliable, commercially accepted language like C/C++ to something
still relatively experimental (D) is to simplify code and maintenance long
term.
The goal is to do the same work we already do with less lines of code. They
should also be cleaner, tidier, less confusing, more informative lines of
code.
Adding a system like you describe to validate virtuals is not a complexity
I'm interested in implementing, it is just one clear reason to sick with
C++. Imagine presenting that to a building full of programmers who
are sceptical about changing from C++ in the first place? What will they
make of such a crude requirement when they already have a perfectly good
virtual keyword in C++?

D offers some amazing steps forwards in terms of powerful meta-programming.
Many typical C/C++ systems that require maintaining (and synchronising)
ugly tables of data, enums, stupid little functions and macros to do
trivial stuff; these can largely be removed in D. It is possible to invent
systems that take code and comprehend it implicitly, generating the desired
functionality, without having to pollute the classes themselves with extra
rubbish used by such a generator (see: user attributes thread).
Removing this sort of crap is something everyone can appreciate. But if we
have to revert to this behaviour to work around a different set of
problems, then we haven't really gained anything.

Code that remains tidy and maintainable for 10+ years (common in gamedev,
game engines live ~2 console generations on average, often longer), but is
still very fluid and dynamic (how gamedev code differs from other
enterprise code, it changes frequently), and doesn't degrade in performance
due to added complexity over years, is, fundamentally, SIMPLE code. It is
also *LESS* code, the fewer lines, the more maintainable as a rule. And
most certainly, code WITHOUT explicit tables of codegen related data; these
are always the first things to rot and fall out of sync. There are often
weird ancillary systems grown around these things to try and auto-magically
maintain them, which themselves are just redundant noise, and contributes
to further complexity and eventual bitrot. I've seen it time and time
again. This is C++'s biggest shortcoming; the language only goes 90% of the
way, and untold complexity is added to achieve the final 10%.

These such sorts of tables are why I fear an enum based serialisation
system, or an enum based virtual function verification system. Who
maintains these tables? It's only a matter of time before some clever
bugger comes along and writes some fancy system to auto-magically manage
these tables, and then every other programmer comes along, has no idea what
to make of it anymore, and wonders what said clever bugger was smoking.
This is just how it works out in practise. Then said clever bugger quits...
>_<

This is one of the key pains I hope to eliminate by using D, but I can't
trade performance for it. The bar is high, competition is staunch, games
consoles are fixed hardware. All the performance tuning mechanisms
available in C/C++ must also be available in D (and generally are, plus
more waiting to be taken advantage of). I shouldn't need to add complex
workarounds for something so trivial as the missing virtual keyword :)


Side note..

I'm a language nerd, and I get excited by D, but I'm trying to think
critically about transplanting it realistically into the commercial
environment. I know what happens there, and it can only be adopted if a
significant numer of C++'s shortcoings are overcome, AND no new
shortcomings are added in the process. Most people aren't interested in D,
they may be sceptical and apprehensive to abandon something with 40 years
of maturity and a whole industry of support. They will not take the risk to
their business for a small number of improvements, especially if they lose
ANYTHING in the process.
It is in my interest to prove to those people undeniably that D is a step
forward in every regard. I believe that is what it will take to allow it to
be adopted widely in the commercial software world.

D is a competitor to C++. I know there are a lot that might disagree with
me, maybe it explores some other avenues too, but in terms of direct
competition to C++ (still the only real choice for realtime programming on
limited systems), there is NOTHING ELSE. I think D needs to embrace what it
is; a native systems language (finally) introducing modern concepts, and by
extension, needs to take performance very seriously.

SIMD support is a great start, I really appreciate that one appearing out
of nowhere almost overnight! :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120324/f517ebe9/attachment.html>


More information about the Digitalmars-d mailing list