<div class="gmail_quote">On 23 March 2012 21:11, Adam D. Ruppe <span dir="ltr"><<a href="mailto:destructionator@gmail.com">destructionator@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Something that *might* help is to do unit tests. Yeah,<br>
that's kinda ass, but it would catch a stray virtual early.<br></blockquote><div><br></div><div>They're not necessarily 'stray' virtuals, they're inappropriate ones</div><div>There's a time and place for virtuals, but there's many more times and places they shouldn't be :)</div>
<div>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.</div><div>The visual cue is important, and the ability to grep for them.</div>
<div><br></div><div>Rememer that virtuals are </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Do a unit test that does a traits check for virtuals:<br>

<br>
<a href="http://dlang.org/traits.html#getVirtualFunctions" target="_blank">http://dlang.org/traits.html#<u></u>getVirtualFunctions</a><br>
<br>
if the name isn't on a list of approved virtuals,<br>
static assert fail.<br></blockquote><div><br></div><div>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</div>
<div><br></div><div>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.</div>
<div>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.</div><div>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++?</div>
<div><br></div><div>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).</div>
<div>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.</div><div><br></div>
<div>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 <i>LESS</i> 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%.</div>
<div><br></div><div>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... >_<</div>
<div><br></div><div>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 :)</div>
<div><div><br></div><div><br></div><div>Side note..</div><div><br></div><div>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.</div>
<div>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.</div></div><div>
<br></div><div>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.</div>
<div><br></div><div>SIMD support is a great start, I really appreciate that one appearing out of nowhere almost overnight! :)</div></div>