"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a5gd$2th1$1@digitaldaemon.com...

> 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?

Other than the inability to produce DLLs (or am I wrong?), I don't really see any problems in writing a COM component. Interfaces won't suite, as Walter has just told us =), but you can always use structures. Function pointers are there as well, so what's the problem?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2a5on$2tj1$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a5gd$2th1$1@digitaldaemon.com...
>
> > 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?
>
> Other than the inability to produce DLLs (or am I wrong?), I don't really see any problems in writing a COM component. Interfaces won't suite, as Walter has just told us =), but you can always use structures. Function pointers are there as well, so what's the problem?
>

No problem, just hadn't thought of that. However, since COM interfaces: have exactly the same functionality as D interfaces you would expect that you would be able to use them. I am just wondering why you can't, it is not like I am not believing Walter or anything....   :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a6jl$2u00$1@digitaldaemon.com...

> have exactly the same functionality as D interfaces you would expect that you would be able to use them. I am just wondering why you can't, it is not like I am not believing Walter or anything....   :)

Maybe because they store ClassInfo?

    // object.d
    struct Interface
    {
        ClassInfo classinfo;
        void *[] vtbl;
    }

Just a thought...

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

> 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."

An idea came to my mind... what if compiler generates an enum for each class, listing all methods introduced in this class (not overridden!), like this:

    class Foo
    {
        // this is what we type
        void bar();
        int baz();

        // and this is what the compiler adds implicitly
        enum vtable
        {
            bar,
            baz
        }
    }

Now we have relative positions of methods in vtable. Using classinfo.vtbl and classinfo.base.vtbl, these can easily be converted to pointers:

    bar_ptr = classinfo.vtbl[classinfo.base.vtbl.length + vtable.bar];

What's also great is that no syntax additions or changes are required, code that would be used to implement this solution is minimal... still all benefits of method pointers are there. What do you think about this, Walter?

Yes, in both cases it is true. And yes, I intend for the ClassInfo to be cast in concrete, however, new members may get appended.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2a5cs$2t7r$1@digitaldaemon.com...
> "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?
>
>

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2a9r5$3077$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a6jl$2u00$1@digitaldaemon.com...
>
> > have exactly the same functionality as D interfaces you would expect
that
> > you would be able to use them. I am just wondering why you can't, it is not like I am not believing Walter or anything....   :)
>
> Maybe because they store ClassInfo?
>
>     // object.d
>     struct Interface
>     {
>         ClassInfo classinfo;
>         void *[] vtbl;
>     }
>
> Just a thought...
>


Seems logical...But maybe it could be tweaked around to be compatible with
COM?
That would be more natural than using structs with tables of function
pointers IMHO...

--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a5gd$2th1$1@digitaldaemon.com...
> 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?

COM requires:
1) the first entry in an object is a vptr
2) the layout of the vtbl[] is exactly like C++ single inheritance
3) stdcall calling conventions
4) AddRef() and Release() memory management.

D Objects fail (2), (3), (4) [(2) because the first entry in the vtbl[] is
the ClassInfo followed by the Object functions].
D Interfaces fail (1), (3), (4).

The solution is to recognize a special root object (strangely enough called "IUnknown" <g>). Deriving from this, instead of from Object, means you wind up with a COM style vtbl[], and it also sets the function calling conventions to stdcall. This has some effects like you can't do a .classinfo on a COM object (no rtti). COM objects are also reference counted, and are not on the garbage collected heap.

It sounds wartier than it actually is. In my experiments, it's much more natural to write COM code in D than it is in C++, despite COM being designed for C++. Portability of this kludge is not an issue, since COM is only for Windows anyway.

It will be possible to write DLLs in D, I just haven't written the necessary library support for it yet.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2aaa5$30k9$1@digitaldaemon.com...
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a2a56s$2t6t$1@digitaldaemon.com...
>
> > 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."
>
> An idea came to my mind... what if compiler generates an enum for each class, listing all methods introduced in this class (not overridden!), like this:
>
>     class Foo
>     {
>         // this is what we type
>         void bar();
>         int baz();
>
>         // and this is what the compiler adds implicitly
>         enum vtable
>         {
>             bar,
>             baz
>         }
>     }
>
> Now we have relative positions of methods in vtable. Using classinfo.vtbl and classinfo.base.vtbl, these can easily be converted to pointers:
>
>     bar_ptr = classinfo.vtbl[classinfo.base.vtbl.length + vtable.bar];
>
> What's also great is that no syntax additions or changes are required, code that would be used to implement this solution is minimal... still all benefits of method pointers are there. What do you think about this, Walter?


It's a great idea, but doesn't work if functions are overloaded. -Walter

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2a9r5$3077$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a6jl$2u00$1@digitaldaemon.com...
>
> > have exactly the same functionality as D interfaces you would expect
that
> > you would be able to use them. I am just wondering why you can't, it is not like I am not believing Walter or anything....   :)
>
> Maybe because they store ClassInfo?
>
>     // object.d
>     struct Interface
>     {
>         ClassInfo classinfo;
>         void *[] vtbl;
>     }
>
> Just a thought...

   ClassInfo pointers can (and should? I don't know the internals of D that
well... but C++ does it that way) be stored in the vtbl (as the [-1]
pointer) and stay COM-compatible.

Salutaciones,
                         JCAB

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2acsb$mj$1@digitaldaemon.com...

> Seems logical...But maybe it could be tweaked around to be compatible with
> COM?
> That would be more natural than using structs with tables of function
> pointers IMHO...

Some special language construct?

BTW also because vtbl is a dynamic array, so it's practically a struct { pointer, int }...