On 03/19/12 08:30, Dmitry Olshansky wrote:
> 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.
Something that should work in theory, but does not behave as expected,
*is* an issue, if it means you can't actually use that solution right now.
[Note the GDC problem may or may not still be there; i tried it a while ago;
the other issues cause enough trouble anyway]
> 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
struct A{}
struct B{A sup; alias sup this;}
void f1(A* a) {/*...*/}
// Fail:
void f2(B* b) {f1(b);/*...*/}
A* b = new B;
// And, yes, "void f1(ref A a);" etc would work, but then it's just a question
// of time before you'll end up searching the whole project for erroneous struct
// copies, instead of virtuals. And the virtual methods are easier to find...
>> 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.
This thread was about larger non-trivial projects, and the difficulty in finding
all methods that do not need to be virtual -- i don't know if replacing the
whole
class hierarchy with a template-mixin-wrapped-in-structs hierarchy would really
be
such a good idea. ;)
Also, see the above example - doing struct inheritance by hand, w/o compiler
help,
quickly gets ugly and dangerous.
>> 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.
I'm saying "use structs instead of classes" is a good suggestion, but *right
now*
the language and compiler do not provide enough support to make this practical.
There's a lot of room for (backwards compatible) improvements, though.
artur
