在普通DLL上使用COM有什么好处?

时间:2009-06-12 14:36:24

标签: c++ com

假设您仅在C ++世界中工作(不需要跨语言互操作)。您在使用COM而不是简单的基本DLL时看到了哪些优点/不便?如果你不打算使用不同语言的界面,你认为使用COM是值得的吗?

7 个答案:

答案 0 :(得分:8)

每个人都在提及COM加列中的内容。我会提到一些违法行为。

  • 使用COM实现系统时,需要在安装时注册COM'服务器'(无论是进程内还是进程外),并在卸载时注销它们。这可能会略微增加安装系统的复杂性,并且往往需要重新启动,除非用户首先小心地删除正在运行的进程。

  • 与执行相同操作的其他标准方法相比,COM速度较慢。这个评论可能会产生很多仇恨,也许会产生一些贬低,但事实上,在某些时候你需要对数据进行编组,这很昂贵。

  • 根据COM规则,一旦界面发布,就永远不会改变。这本身并不是消极的,您甚至可能会争辩说它会在发布界面之前强制您进行彻底的设计。但事实是,从来没有这样的事情,并且在生产代码接口中也会发生变化。毫无疑问,您需要添加方法或更改现有方法的签名。为了实现这一点,你必须要么破坏COM的规则 - 这会产生不良影响 - 或者遵循COM的规则,这些规则比仅仅使用astraight DLL一样向函数添加参数更复杂。

答案 1 :(得分:6)

COM在普通的旧C ++中非常有用:

  • 进程间通信
  • 插件架构
  • 后期绑定方案
  • “多,多,多......”(tm)

那就是说,如果你不需要它,不要使用它。

答案 2 :(得分:5)

使用DLL可以获得更紧密的耦合,而COM可以非常精确地限制交互。这是优点和缺点的根源!

您获得了更多的功能和灵活性(例如,从DLL中定义的类继承,在COM中不可行),但依赖性因此更强(需要重建用户以对DLL进行某些更改等)。

通常特别令人烦恼的是,所有DLL和EXE必须使用相同类型的运行时库和选项(例如,所有动态链接到msvcrt*的非调试多线程版本 - 无法重建一个使用调试版本而不会产生很可能的错误!)。

因此,COM的松散耦合通常是可取的,除非你真的需要在特定情况下更紧密耦合的各种交互(例如,一个框架,它肯定要求用户代码从其类继承,应该是一个DLL )。

答案 3 :(得分:2)

如果可以避免不使用它。在我的上一个项目中,COM为使用的C ++接口带来了很多限制。试想一下,你不能简单地传递一个std :: string但必须使用一个字符数组。在这种情况下,您构建字符串,然后将其复制到可以由COM处理的数组。

您也只能使用非常有限的一组基本类型,具有强制转换和专有内存管理。你不能使用new / delete,但必须使用COM自己的函数。

你也不能简单地抛出异常,但必须初始化一些COM接口IErrorInfo,它将在另一端重新抛出。

因此,如果您不需要,请不要使用它。它肯定会搞砸你的设计。如果你需要它,尝试评估其他互操作可能性:boost :: interprocess,zeroc ice ......

此致

Ovanes

答案 4 :(得分:1)

  • 注册和发现
  • 外的过程
  • 远程调用

是您可以获得的一些额外功能。即使是事务支持也可以在不需要COM支持的情况下流动。

答案 5 :(得分:1)

IUnknown接口无论如何都是一个很好的基础级别 - 让您在不破坏旧客户端(QueryInterface)和普遍引用计数的情况下添加功能。你可以实现这一点,而无需购买COM中的所有内容。

然后,每当你向一个类添加一个特性时,如果你使用它的COM接口,你至少得到一个已知的接口 - 例如IDispatch,如果你想要反射特征。

你唯一能够被其他语言调用的三角洲就是注册和工厂。

答案 6 :(得分:1)

因为接口独立于任何特定的DLL,在最简单的层面上,类似COM的方法至少可以让您更改为引擎下的接口提供服务的dll,而无需根据新的dll名称重新编译应用程序。

将完整COM与MIDL定义的接口和代理存根dll一起使用意味着您可以使用COM来管理同一台PC上的线程安全进程间通信,进程间通信,甚至可以连接到远程PC上的COM服务器对象。