COS组件系统理解

COS组件系统理解

1．  Cos 中的 GetIf 也就相当于 COM 中的 queryinterface ，可以从此 cos 组件支持的任意接口通过此函数获取其它支持接口的指针。

2.  pOuter 指针是用来做 com 中的 aggregation 用的 ， 比如 annimal 的 pOuter 指针指向 kolaa 对象 ，使Ianimal接口可以查询到Ikoala接口。

 

 

3．  接口原则上是不能有变量数据的，如果要实现每个接口实例要有自己的变量而且不暴露给客户，例

暴露给用户的 ex.h               

INEW

{

…

GetI();

SetI();
};

内部的 .h

INEWIn

{

…

GetI();

SetI();

Int I;
};

用户使用 INEW 但在内部 转换成 INEWIn 操作； inside ole 第二章 ENUMRECT 例子多用了一个 vtbl 结构体隔离接口和实现相比上一方法更好点，但这种方法如果用 c 语言的 client 使用此组件，则取得组件接口指针后要 PIntface->vtbl->func(), 这样调用， c++ 的 client 则直接 PIntface->func() （ COM 中可以， cos 不行见 8 ）。

4. 每个接口有计数， cos 组件本身也有计数。

5. COM 中的 queryinterface 实际上是用把 this 指针强制类型 static_cast 转换成其他接口的指针来实现的，而 COS 里更简单（ c 语言），每个接口实例都是一个全局的变量，通过匹配接口标志就返回全局变量的指针就行。

6. 在 C++COM 中，实现是继承接口的，在 createinst 时只实例化实现，而在 c 语言中， vtbl 结构体全是函数指针，接口包含 vtbl 的指针，实现是另一个结构体包含了 vtbl 的指针并且有变量，实现被实例化，而 vtbl 结构体被置为全局变量，详见 insideole 第二章 ENUMRECT 例子程序， cos 其没有 vtbl 的结构体，而是实现的结构体继承了接口结构体（ IGet ，其实 IGet 严格意义上不是一个接口，其中有 ref 变量，为了方便使用）， cos 这样干违背了 com 的二进制规范吗？？有什么影响呢？？？待进一步理解 com 。

7. 引用计数

规则：全局变量：对于保存在全局变量中的接口指针，在将其传递给另外一个函数前，必须调用其 addref ，由于此变量是全局性的，应此任何函数都可以通过调用其 release 来终止其生命，对于保存在成员变量中的接口指针，也应这样，因为对于所有成员函数来说，他是全局的。（适用于 cos ）

8 ．关于 COS 与 COM 的不同之处： COS 编出来的实际上是一个 BIN （相当于 EXE ）是可执行文件，而 COM 编出来的是一个 DLL 不是可执行的， com 的 c 组件和 c++ 组件保持二进制兼容就可以直接互调，而 cos 不行： cos 编出来的是个 bin ，这个 bin 在头上的固定位置有几个固定的接口，另外的一个客户程序要 load 这个 bin ， load 程序就去查 bin 头的这几个接口，这几个接口负责解析整个 bin 提供出来的功能接口，这样 load 程序就不用自己去遵循某种协议去自己搜索 bin 的功能接口，所以在编程时 c 程序做成跟 c++ 保持二进制兼容的在 cos 里没用，一个 cos 的 c++ 程序调用 load 去加载 bin ， c++ 程序的 load 是不去解析 bin 的，而是 bin 自己的 appentry 去解析自己的 bin 的，所以 c++ 程序也看不到 c 程序的二进制兼容的结构，只有它自己的 bin 的 appentry 看得到。

         当时 cos 设计时有两种选择： 1. 就是现在的设计思路； 2. 不把 cos 编成 bin 而是编成类似于 dll 的 ELF 格式，这样由比如说 c++ 的客户程序去加载此 cos ，然后使用（跟 COM 一样）， c++ 客户程序去加载时，客户的 load 程序就要去解析 elf 格式，由于 elf 格式有很多头信息，解析比较麻烦，所以 load 要能解析 elf ，才能让客户看到 c 的兼容二进制功能接口，这样比第一种复杂，在嵌入式环境里也很复杂。