I wonder if I can rely on the order of methods in vtable being the same as order of their declaration?

    class Something
    {
        void qwerty();
        void asdf();
    }
    Something thing;
    ...
    thing.classinfo.vtbl[thing.classinfo.vtbl.length - 1]; // asdf()?
    thing.classinfo.vtbl[thing.classinfo.vtbl.length - 2]; // qwerty()?

It seems to work with DMD, but is it portable?

Also, does the same apply to interfaces (it should, IMO, since interfaces sometimes just ought to have fixed, predefined order of methods - if used with COM, for example....)

Pavel Minayev a écrit :

> I wonder if I can rely on the order of methods in vtable being the same as order of their declaration?
>
>     class Something
>     {
>         void qwerty();
>         void asdf();
>     }
>     Something thing;
>     ...
>     thing.classinfo.vtbl[thing.classinfo.vtbl.length - 1]; // asdf()?
>     thing.classinfo.vtbl[thing.classinfo.vtbl.length - 2]; // qwerty()?
>
> It seems to work with DMD, but is it portable?

At last you got it (vtbl) ?
For portability and readeability it would be nice something like
    thing.classinfo.vtbl.qwerty

(why do i always have ideas for _more_ work for walter and never for _less_
?)

Roland

"Roland" <rv@ronetech.com> wrote in message news:3C486B82.F2E11B62@ronetech.com...

> At last you got it (vtbl) ?

? It always was there!

> For portability and readeability it would be nice something like
>     thing.classinfo.vtbl.qwerty

Why if you can write "thing.qwerty" ? =)

One great thing would be an associative-array vtable
(and one for properties as well, storing their offsets
from "this"):

    thing.classinfo.method["qwerty"];
    thing.classinfo.property["asdf"];

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a29jef$1d1a$1@digitaldaemon.com...
> Also, does the same apply to interfaces (it should, IMO, since interfaces sometimes just ought to have fixed, predefined order of methods - if used with COM, for example....)


I doubt the order will be anything but declaration order.

(COM won't work with interfaces, for some obscure technical reasons. I found
another way to do it.)

Pavel Minayev a écrit :

> "Roland" <rv@ronetech.com> wrote in message news:3C486B82.F2E11B62@ronetech.com...
>
> > At last you got it (vtbl) ?
>
> ? It always was there!
>

? don't see in the spec.
vtbl propertie is the virtual table right ?
 For a little while, I suspect you to make some kind of pointer to
methode replacement writing in the vtbl.
good idea..

> > For portability and readeability it would be nice something like
> >     thing.classinfo.vtbl.qwerty
>
> Why if you can write "thing.qwerty" ? =)

I agree, can you now ?
If yes, i missed the conclusion of a previous discussion.

Roland

"Walter" <walter@digitalmars.com> wrote in message news:a29vu9$2ppj$1@digitaldaemon.com...

> I doubt the order will be anything but declaration order.

In _both_ cases (the first would be better!).
I'm still searching for the solution of method pointers - well you've
probably guessed =) - so now it seems I've found it.

BTW is the ClassInfo stuff implementation-dependent or it is
supposed to be strictly defined? In other words, can I rely
on the fact that on any platform ClassInfo contains void*[] vtbl?

"roland" <nancyetroland@free.fr> wrote in message news:3C489394.B3380956@free.fr...

> ? don't see in the spec.

The best spec is Phobos source, see the files object.d and cast.d, how it is used here. Also new.cpp contains code that shows how to create an instance of object by its ClassInfo, bypassing operator new; unfortunately, constructor is not called...

> vtbl propertie is the virtual table right ?

Right. Here's the whole thingie:

    class ClassInfo : Object
    {
        byte[] init;  // class static initializer
        char[] name;  // class name
        void *[] vtbl;  // virtual function pointer table
        Interface[] interfaces;
        ClassInfo base;
        void *destructor;
        void (*_invariant)(Object);
    }

Quite interesting...

>  For a little while, I suspect you to make some kind of pointer to
> methode replacement writing in the vtbl.
> good idea..

Yes. If order of methods in vtbl is as they're declared, we can always get the address of last method, one before the last, etc. So:

    class MyForm
    {
        this()
        {
            // offset from end of vtable is used as function pointer
            cmdOk.OnClick = Handler.cmdOk_Click;
            cmdCancel.OnClick = Handler.cmdCancel_Click;
        }

        // various methods
        ...

        void cmdOk_Click() { ... }
        void cmdCancel_Click() { ... }
        // reversed order (count from end)
        enum Handler { cmdCancel_Click, cmdOk_Click }
    }

> > Why if you can write "thing.qwerty" ? =)
>
> I agree, can you now ?

You mean to get an address of method? No, I asked Walter about that already:

    "For an answer right now, it'll be "no". Doesn't mean it will always
    be that way, doesn't mean that method pointers are a bad idea, I just
    am buried with work and I can't address it now."

Funny, you can write something like &qwerty, which gets parsed fine but causes the compiler to crash later =)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2a4os$2sr5$1@digitaldaemon.com...

> In _both_ cases (the first would be better!).

Sorry forgot to put the ? at the end =)
So, in both cases?

"Walter" <walter@digitalmars.com> wrote in message news:a29vu9$2ppj$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a29jef$1d1a$1@digitaldaemon.com...
> > Also, does the same apply to interfaces (it should, IMO, since interfaces sometimes just ought to have fixed, predefined order of methods - if used with COM, for example....)
>
>
> I doubt the order will be anything but declaration order.
>
> (COM won't work with interfaces, for some obscure technical reasons. I
found
> another way to do it.)
>

Yes, I meant to ask that? Is it possible to work with / write COM components
in D?  How does it work? You would think interfaces would be perfectly
suited
to COM?