virtual-by-default rant
Artur Skawina
art.08.09 at gmail.com
Sun Mar 18 15:17:00 PDT 2012
On 03/18/12 15:37, Dmitry Olshansky wrote:
> On 18.03.2012 5:23, Manu wrote:
>> The virtual model broken. I've complained about it lots, and people
>> always say "stfu, use 'final:' at the top of your class".
>>
>> That sounds tolerable in theory, except there's no 'virtual' keyword to
>> keep the virtual-ness of those 1-2 virtual functions I have... so it's
>> no good (unless I rearrange my class, breaking the logical grouping of
>> stuff in it).
>> So I try that, and when I do, it complains: "Error: variable
>> demu.memmap.MemMap.machine final cannot be applied to variable",
>> allegedly a D1 remnant.
>> So what do I do? Another workaround? Tag everything as final individually?
>>
>> My minimum recommendation: D needs an explicit 'virtual' keyword, and to
>> fix that D1 bug, so putting final: at the top of your class works, and
>> everything from there works as it should.
>
> Following this thread and observing that you don't trust optimizer and compiler in many cases or have to double check them anyway, I have a suggestion: do virtual dispatch by hand via func-pointer table and use structs.
>
> I'm serious, with a bit of metaprogramming it wouldn't be half bad, and as a bonus you don't have to pay for a monitor field per object as classes do, and in general less compiler magic to keep track of. You also gain the ability to fine tune their layout, the performance maniac side of yours must see the potential it brings :)
I was going to suggest the very same thing - but there are (at least) two problems
with that approach:
1) pass-by-value -- it's dangerous, ugly to work-around (and compiler bugs don't
help, like the one where just having a "this(this)" causes problems); the
workarounds also have compiler/ABI issues (like the 'File' case posted in D.learn
some time ago, or GDC not passing/returning the pseudo-refs in registers)
2) no inheritance. ie 'struct A{}; struct B{A super; alias super this;}' cannot be
written as just 'struct B:A {}' - which would not be just syntax sugar, but also
allow (more) implicit conversions, (explicit) function overrides etc.
So - yes, D structs should be enough for everything, but right now they're still
missing some required basic features. Ideally "class" would just be sugar, and
everything should be expressible using just structs - obviously in a much more
verbose, but 100% compatible way (incl vtables, monitors etc)
After all, real programmers don't use classes. :)
artur
More information about the Digitalmars-d
mailing list