Re: Virtual destructors and vtable layout
On Oct 12, 2:44 am, "Ole Nielsby"
<ole.niel...@tekare-you-spamminglogisk.dk> wrote:
James Kanze <james.ka...@gmail.com> wrote:
On Oct 11, 4:21 am, "Ole Nielsby"
<ole.niel...@tekare-you-spamminglogisk.dk> wrote:
James Kanze <james.ka...@gmail.com> wrote:
The vtable layout used by the C++ compiler has nothing
to do with what the component model does. None of the
component models I'm familiar with even use a vtable,
except insofar as they map to C++ code, in which case,
they're just normal C++ code.
COM does rely on vtable layout. COM interfaces are
declared as pure virtual classes, all methods using
stdcall convention, and this works because most (if not
all) C++ compilers for the MSW use a very similar vtable
layout.
In other words, COM is pretty much unusable.
COM is a mess - but very usable.
Only in very limited contexts. And it probably should be
avoided even then, because its limitations prevent future
growth. If you can't easily move a component from one machine
to another, there's really no point in using a component
architecture, is there?
Seriously, you've got to be kidding. How does it work when the
components are on different machines? Running different
binaries with the functions at different addresses?
By client proxies that communicate with the server components
using the network. The system libraries supply proxies for
common interfaces.
In that case, who cares how the vtable is laid out. The proxy
is compiled in whichever language you want, and has the correct
vtable for that language and that compiler.
That's really how Corba works. (At that particular
level---there's a lot more to Corba. Which is nice if you
need it, and a major overhead if you don't.)
Either it's not really a component model, but just a means
of supporting linking different languages (which,
admittedly, all systems should provide), or you've
misunderstood something.
I think COM does qualify as a component model, though not a
particularly consistent one. I know for sure that the C++
headers used by C++ COM programs do rely on the compiler using
a specific layout for the vtables. This may be undefined
according to the C++ standard but it's very widely used.
But if the COM interface definition is in C++, you can compile
it to another language, using that language's binding. And if
you're using proxies, the vtable layout doesn't matter. And
can't; it makes no sense to say that the vtable layout is the
same on a Sparc as it is on a PC.
But if I understand you correctly, COM mixes two very different
concepts: a component model (using proxies, etc.), and a
specification for a mixed language platform specific API. The
latter needs a lot more than just a consistent vtable layout, of
course, but presumable, Microsoft ensures that all the rest
works as well in the tool chains it provides. (The problem is
that except for C++, and maybe C#, it doesn't provide any other
useful language. In mixed language programming, the "other"
language is usually either a legacy language---Cobol or
Fortran---or a language targetting a different model, like Perl,
Python, Ruby or Java.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34