On 19.03.2012 2:17, Artur Skawina wrote:
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)
GDC not passing pseudo-refs in registers is cleanly a non-issue, in a
sense, that it's not a good excuse at all, as well the other bugs.
All in all, nobody is going to kill you if in performance sensitive code
you'd use pointers:
BigStruct* my_big = allocateSomewhere(...ctor_args...); //ultimately
using emplace
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.
Template mixins? I envision:
struct Foo{
mixin Inherit!(Bar);
}
I see that it is not a cake-walk but acceptable for the special nature
of requirements.
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)
Yes, that the point. And if one doesn't like this kind of compiler
sugar, he is free to synthesize Xylitol.
--
Dmitry Olshansky
