Re：虚拟析构函数和vtable布局 [英] Re: Virtual destructors and vtable layout
问题描述
James Kanze< ja ********* @ gmail.comwrote：
James Kanze <ja*********@gmail.comwrote:
C ++编译器使用的vtable布局无关
与组件模型的作用。没有任何组件
模型我甚至不熟悉使用vtable，除非他们将b / b
映射到C ++代码，在这种情况下，他们只是普通的C ++
代码。
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确实依赖于vtable布局。 COM接口被声明为
作为纯虚拟类，所有方法都使用stdcall约定，而
这是有效的，因为大多数（如果不是全部）MSW的C ++编译器
使用非常相似的vtable布局。
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.
当你想到它时，它们怎么可能？通常的vtable
实现包含指向本地进程的指针;通过
定义，一个组件模型允许在进程之间进行调用，
，通常在具有不同体系结构的机器之间进行调用。
（否则，为什么要烦恼它。）
How could they, when you think about it? The usual vtable
implementation contains pointers into the local process; by
definition, a component model allows calling between processes,
and generally between machines with different architectures.
(Otherwise, why bother with it.)
在COM中，这由系统dll提供的代理处理，
并且它们依赖于相同的vtable布局。 />
In COM, this is handled by proxies provided by system dlls,
and they rely on that same vtable layout.
如果您正在设计一个插件界面，那么您可以自行决定如何定义它，但通常是至少在Windows和Unix下，
它是用C语言定义的，以利用系统范围的C
语言API。
If you''re designing a plugin interface, it''s up to you to decide
how to define it, but usually, at least under Windows and Unix,
it''s defined in terms of C, to leverage off the system-wide C
language API.
严格来说，COM和UNO接口是用IDL的
术语定义的，但是使用C ++类是常见的做法< br $> b $ b（我不认为我曾经见过这些东西编码为明确的vtable
in C.）
Strictly speaking, COM and UNO interfaces are defined in
terms of an IDL but it''s common practise to use C++ classes
(I don''t think I''ve ever seen this stuff coded as explicit vtables
in C.)
推荐答案
James Kanze< ja ********* @ gmail.comwrote：
James Kanze <ja*********@gmail.comwrote:
10月11日凌晨4:21，Ole Nielsby
< ole.niel ... @ tekare-you-spamminglogisk.dkwrote：
On Oct 11, 4:21 am, "Ole Nielsby"
<ole.niel...@tekare-you-spamminglogisk.dkwrote:
James Kanze< james.ka ... @ gmail.comwrote：
James Kanze <james.ka...@gmail.comwrote:
C ++编译器使用的vtable布局无关
与组件模型的作用。没有任何组件
模型我甚至都熟悉甚至使用vtable，除非他们映射到C ++代码
，在这种情况下，他们只是正常
C ++代码。
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确实依赖于vtable布局。 COM接口被声明为
作为纯虚拟类，所有方法都使用stdcall约定，而
这是有效的，因为大多数（如果不是全部）MSW的C ++编译器
使用非常相似的vtable布局。
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.
换句话说，COM几乎无法使用。
In other words, COM is pretty much unusable.
COM很乱 - 但非常实用。
COM is a mess - but very usable.
说真的，你必须要开玩笑。当
组件在不同的机器上时，它是如何工作的？使用不同地址的函数运行不同的
二进制文件？
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.
要么它不是真正的组件模型，而只是一种
支持链接不同语言（不可否认，所有
系统都应该提供），或者你误解了一些东西。
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.
我认为COM确实有资格作为组件模型，但
不是特别一致的。我确信C ++ COM程序使用的
C ++标头确实依赖于编译器使用vtable的特定布局。根据C ++标准，这个
可能是未定义的，但它是非常广泛使用的
。
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.
On 10月12日，2：44 * am，Ole Nielsby
< ole.niel ... @ tekare-you-spamminglogisk.dkwrote：
On Oct 12, 2:44*am, "Ole Nielsby"
<ole.niel...@tekare-you-spamminglogisk.dkwrote:
James Kanze< james.ka ... @ gmail.comwrote：
James Kanze <james.ka...@gmail.comwrote:
10月11日凌晨4:21，Ole Nielsby
< ole.niel ... @ tekare-you-spamminglogisk.dkwrote：
On Oct 11, 4:21 am, "Ole Nielsby"
<ole.niel...@tekare-you-spamminglogisk.dkwrote:
James Kanze< james.ka .. 。@ gmail.comwrote：
C ++编译器使用的vtable布局没有什么与组件模型有关的
。即使使用vtable，
也不熟悉
组件模型，除非它们映射到C ++代码，在这种情况下，
他们只是普通的C ++代码。
James Kanze <james.ka...@gmail.comwrote:
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依赖于vtable布局。 COM接口是
声明为纯虚拟类，所有方法都使用
stdcall约定，这是因为大多数（如果没有
all）C ++ MSW的编译器使用非常相似的vtable
布局。
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.
换句话说，COM几乎无法使用。
In other words, COM is pretty much unusable.
COM很乱 - 但非常实用。
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.
在这种情况下，谁在乎如何布置vtable。代理
是用你想要的任何语言编译的，并且对于那种语言和编译器有正确的
vtable。
这就是Corba的工作方式。 （在那个特别的
级别 - 对Corba来说还有更多。如果你需要它，那么这是很好的，如果你没有，那么这是一个很大的开销。 t。）
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.
我认为COM确实有资格作为组件模型，但不是特别一致的
。我确信C ++ COM程序使用的C ++
标头确实依赖于编译器使用
vtable的特定布局。根据C ++标准，这可能是未定义的
，但它被广泛使用。
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.
但是如果COM接口定义是用C ++编写的，你可以使用该语言的绑定将它编译成另一种语言。如果
你正在使用代理，那么vtable布局并不重要。并且
不能;在Sparc上的vtable布局与在PC上的布局相同是毫无意义的。
但如果我理解正确， COM混合了两个非常不同的
概念：一个组件模型（使用代理等），以及一个混合语言平台特定API的
规范。
后者需要的不仅仅是一个一致的vtable布局，
当然，但可以推测，微软确保所有其余的
工作以及它提供的工具链。 （问题是
，除了C ++，也许是C＃，它没有提供任何其他的有用的语言。在混合语言编程中，其他也是如此。
语言通常是遗留语言--- Cobol或
Fortran ---或者是针对不同模式的语言，如Perl，
Python，Ruby或Java。）
-
James Kanze（GABI Software）电子邮件：ja ********* @gmail .com
Conseils eninformatiqueorientéeobjet/
Beratung in objektorientierter Datenverarbeitung
9placeSémard，78210 St.-Cyr-l''colele ，法国，+ 33（0）1 30 23 00 34
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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l''école, France, +33 (0)1 30 23 00 34
James Kanze< ja ********* @ gmail.comwrote ：
James Kanze <ja*********@gmail.comwrote:
[...]
但是如果我理解正确的话，COM会混合两个非常不同的b
概念：组件模型（使用代理等），
和混合语言平台规范的规范c API。
[...]
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.
我认为这是正确的。
I think that''s correct.
后者需要的不仅仅是一致性vtable布局，
当然，但可以推测，Microsoft确保所有其余的
在它提供的工具链中也能正常工作。
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.
它也适用于非MS编译器。 COM组件可以由VC，Borland，GCC编译，并且仍可以通过兼容的vtable协同工作
。
XPCOM（Mozilla / Firefox组件模型）和UNO
（OpenOffice的组件模型）工作方式大致相同
方式。
我认为选择这种接口是因为它在进程中使用时的开销很低 - 只需要跨越一个
组件边界是虚拟的呼叫。因此它符合
按使用付费的理念：只有在您需要的情况下，才需要支付编组费用
。
IMO如果C ++有一些方法可以执行
a标准vtable布局，那将是很好的。那些组件模型如
这可以在不依赖严格的情况下使用/>
说未定义的beaviour。
It works with non-MS compilers, too. COM components can
be compiled by VC, Borland, GCC... and still work together
by virtue of compatible vtables.
XPCOM (the Mozilla/Firefox component model) and UNO
(the component model of OpenOffice) work much the same
way.
I think this style of interfacing was chosen because of its low
overhead when used in-process - all it takes to cross a
component border is a virtual call. So it fits with the
pay-per-use philosophy: you pay for the marshalling
only if you need it.
IMO it would be nice if C++ had some way of enforcing
a standard vtable layout.so that component models like
this could be used without relying on what is strictly
speaking undefined beaviour.
这篇关于Re：虚拟析构函数和vtable布局的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
