HOME REPUB

C++的接口与非侵入式接口

本来是要哀悼一下 COM 以及 ATL,但是在此之前,先铺垫一下接口的知识,以及一点深入的探讨。现在看来,接口在静态类型的面向对象语言中,好比 Java、C#,地位显赫,猿语只要敢声称其支持面向对象的理念,那么其语言机制中必定存在接口的概念,哪怕 go 语言不待见继承(其实继承是很好抽象手段),它也有接口的语法,并且据说还是唯一必须保留的特性。

众所周知,C++ 里面的接口与众不同,接口实现与类实现混为一体,或者说,接口并没有享受到其一等公民的对待。虽然 C++ 通过多继承的方式来支持接口的编程理念,首先是要求基类不得包含任何字段,类里面只有方法,且必须要有纯虚函数,这个时候,类的对象的大小就只等于一个指针,也就是虚函数表指针,然后子类继承该基类并重写全部的纯虚函数。但是这种方式只是对接口的 walkaround,意思就是刚好 C++ 的多继承好像可以支持接口理念,好像行得通,但这只是幻觉,说的再好听,编译器内部实现中依旧将接口当成类来对待, 接口里面不得包含字段 的关键规定重要信息并没有被充分利用起来。显然,原本接口就应当是比类更加轻量级的语言机制,编译器实现可以给予专门的优化或者更特别的照顾,用类的概念来套接口,实在有点铺张浪费。

C++ 采用多继承纯虚基类的方式来搞接口,最不能忽视的必然就是其空间上的开销,比如说,一个类如果实现 N 个接口,那么该类的任何一个对象首先起码必须包含这 N 个接口的虚函数表指针,哪怕对象没有被当做是接口来使用,这个开销也都无法避免,这就不零惩罚抽象了。在 C++ 中,只要违反了这条戒律,就意味该方案有待改进。不为不需要的特性付出任何代价是最高指导原则,只有满足了这条原则的设计才是好的设计。

宏观上来看,多继承的方式来实现接口,死板,缺乏弹性,对象的内存布局难以捉摸,导致在二进制的复用上困难重重。最大的弊端还是在于,一旦类的定义完成了,这个类所实现的接口也就确定下来啦,无增无减无改。当然,如果需要,我们也可以修改类的定义,再多继承多几个接口,再重写多几个虚函数。但是,如果不能修改类的定义,比如说面对着原生基本类型 int float double 的时候怎么办?就更别提要让模板类 vector list 也享受上接口的荣誉了。接口比类更轻量级意味着接口对客户端的要求更少,意味着接口的具备着更大的通用性。因此,我们必须寻求新的方法来诠释(落实)接口这个美妙的概念,更具体地说,就是如何充分利用接口不包含任何字段这条重要信息。

自然,接口依旧是不包含字段的基类,并且里面存在纯虚函数。题外话,原则上,接口也可以人肉虚函数表,手写声明各个成员函数指针原型,好像 C 语言实现 COM 接口的那样,体验很不友好,虽然能多一点点灵活性以及自由度,但是工作量相当巨大,并且也丧失了编译器类型安全的好处。总之,要充分利用 C++ 编译器的每一个功能。比如说,我们就假设搞了这样的一个接口

struct TextWriter;
struct TextReader;
struct FormatState;

struct IFormatble
{
        virtual void Format(const TextWriter& stream, const FormatState& state) = 0;
        virtual void Parse(const TextReader& stream, const FormatState& state) = 0;
};

对此,编译器马上就为这个接口生成了一个虚函数表,表里面起码包含了2个条目,按顺序(顺序很重要)分别对应了虚函数 Format 和 Parse。接下来,我们就要让 int 来实现这个接口啦。显然,无法这样写,struct int : IFormatable{…}。就算可以写,那么 int 类型变量的大小马上就不仅仅只是 sizeof(int),还得再背负多一个指针大小。这完全就不是我们想要的。还拿 int 来说,我们期望,int 变量在参与格式化的时候才出现那个虚函数表指针,不格式化时,自然就不劳烦这个指针了。天底下有这么好的事情吗?有的,软件开发中的万能丹, 任何问题都可以通过添加间接层来解决 ,一层不够,就加多几层,总是有办法的。

struct ImpIntIFormatable : IFormatble
{
        int* mThis;
        virtual void Format(const TextWriter& stream, const FormatState& state) override
                {
                        //......
                }

        virtual void Parse(const TextReader& stream, const FormatState& state) override
                {
                        //......
                }
};

从内存布局上看,ImpIntIFormatable 用 C 语言的结构体来表达就是这样

struct Layout4ImpInt
{
        const void* mVtbl;
        int* mThis;
};

显然,这个结构体很有普世价值,稍微升华一下,就可以当做是任意接口的实现典范了。

template<typename ObjTy, typename ITy>struct TraitOf;

template<typename ITy>
struct TTrait
{
        const void* mVtbl;
        void* mThis;

        operator ITy*()const
                {
                        return (ITy*)(void*)this;
                }

        ITy* operator ->()
                {
                        return (ITy*)(void*)this;
                }

        template<typename ObjTy>
        TTrait(ObjTy& obj)
                {
                        typedef typename TraitOf<ObjTy, ITy>::type Imp;
                        Imp imp;
                        memcpy(this, &imp, sizeof(*this));
                        mThis = &obj;
                }
        //...
};

有了接口以及实现,接下来,自然就是将二者有机地结合起来使用。用人话来说,还是以 int 为例子吧,就是在将 int 变量传递到格式化操作中时,要如何让编译器找到 ImpIntIFormatable,进而生成接口实现者的内存布局。用模板偏特化。在 Java 下,就比较惨了,必须用所谓的适配器。

template<>
struct TraitOf<int, IFormatble>
{
        typedef ImpIntIFormatable type;
};

void DoFormat(TTrait<IFormatble> tt)
{
        //...
}

void FF()
{
        int aa;
        DoFormat(aa);
}

以上代码,为了清晰的表达示意图,跳过了很多错误处理并忽略可扩展性了。本座的 C++ 非侵入式接口重构了几十遍,考虑了继承,模板,反射,并用它打造了 IO,json,xml,数据库读写,网络库,界面库,……,总之,用起来很得心应手啊,深深地感受到大 C++ 的伟大光辉,论非侵入式接口(或者说 trait)的粒度控制以及可定制性,还数大 C++ 做得最好,go 或者 rust 之类的非侵入式,怎能跟大 C++ 相提并论,萤火之光岂能与皓月争辉。

因此,在 C++ 下,我们就重新诠释了接口。这里的关键在于接口基类中不得包含字段,这些手法才得以成立。另外,明眼人一眼就看出来,上面的方案假设虚函数表指针就一定放在对象的首地址上,这没什么不好,主流的编译器都是这么做。不这么搞的编译器都是异端,要烧死它们。为什么要标新立异,不把虚函数表指针放在对象的首地址上呢,这完全就是自绝于广大人民之前,咎由自取,自取灭亡。