C++ Template 技巧 （一）

一、基于Policy的class设计

1. C++常用的解决问题的方法

• Objects

• Event

• Observers

• Callbacks

• Virtuals

• Template

  ​ C++就是这样一种十分灵活的语言，它支持面向过程编程，面向对象编程，函数式编程，泛型编程，模板元编程。它的选择都有很多，而每一个选择都会开启了一个新世界，一旦你选择了一个解决方案。随之而来的就是应对软件中各种变化，如何快速迭代优化，构建可复用，灵活可拓展的库，成功与否就是前期的一道选择题。

2. 程序的要求

强的弹性和优良设计

在编译期强制表现出大部分的限制和规范(constraints)

六大设计原则

3. 解决方法

多重继承：缺乏型别信息，容易扩张

Template：丰富的型别信息，无法扩张

将templates和多重继承组合起来 => 非常具有弹性的device/component

4. 例子

(1) 接口组成:

​ 内隐型别定义(inner type definition)

​ 成员函数(member function/method)

​ 成员变量(member data)

(2) 使用方面

• traits
• strategy

(3) 例子

设计要求：

• 生成对象回传指针
• 统一使用Create方法
• 三种生成方法：(1)new (2)malloc + placement new (3)clone

一种实现代码为:

// polices

template<typename T>
struct OpNewCreator
{
    static T* Create()
    {
        return new T;
    }
};

template<typename T>
struct MallocCreator
{
    static T* Create()
    {
        void* buf = std::malloc(sizeof(T));
        if (!buf) 
        {
            return 0;
        }
        
        return new(buf) T;
    }
};

template<typename T>
struct PrototypeCreator
{
    ProrotypeCreator(T* pObj = 0):
    	pPrortype_(pObj)
    {}
    
    T* Create()
    {
        return pPrototype_ ? pPrototype_->clone() : 0;
    }
    
    T* GetPrototype() const 
    {
        return pPrototype_;
    }
    
    void SetPrototype(T* pObj)
    {
        pPrototype_ = pObj;
    }
    private:
    T* pPrototype_;
};

// library code or user code
template<typename CreationPolicy> // host classes
class WidgetManager : public CreationPolicy
{
    //...
};

// user code
typedef  WidgetManager<OpNewCreator<widegt>> MyWidgetMgr;

(4) 上述代码分析

1) policies接口和classes接口

• policies接口是语法导向接口(syntax oriented)
• classes是标记导向接口(signature oriented)

​ 标记导向接口所作出的要求更加严格

​ 语法导向接口并没有规范接口的签名，例如：Creator Policy并没有规定Create()是static ,还是virtual，Creator也只是规定了返回值应该返回一个指向新对象的指针，但是我们是现实却可以让他返回0，甚至可能抛出异常。我们仅仅需要有一个Create()函数即可，借助C++ 变模板参数，我们甚至可以连Create的传入参数都不做要求。

2) 模板模板参数(template template 参数)

​ 在运用policy时，template的参数往往显得有点多余，使用者每次都需要传入template参数，这显得有些笨拙。除非生成管理任何一种类型的模板类，一般来说，hostclass已经知道或者可以推导出来。比如在组装WidgetManager类总是操作Widget，我们只需要变化不同CreationPolicy即可。这样还要把Widget传给OpNewCreator显得多余且危险。这个时候使用模板模板参数即可：

// Library code
template<template<typename Created> typename CreationPolicy>
class WidgetManager : public CreationPolicy<Widegt>
{
    // ...
};
// Created 是CreationPolicy的参数，CreationPolicy则是WidgetManager的参数。

// Application code
typedef WidgetManager<OpNewCreator> MyWidgetMgr;

​ Created虽然露出脸来了，但是对widgerManager并没有作用。因为你不能在WidgetManager使用Created，他就像是func(int a)但是函数并没有使用a,，所以你可以省略他们。因为他们只是形式参数(formal argument)。**<template<typename Created>>**唯一的作用是指明Creationpolicy是一个模板且只需要一个参数。因此，你可以像上面的Application那样使用他们。当然，这种写法，明确指明了CreationPolicy是一个模板，类里面就可以随便组装CreationPolicy。比如：在WidgetManager产生一个以相同的方法生成的另一个对象，代码如下:

template<template<typename> typename CreationPolicy>
class WidgetManager : CreationPolicy<Widget>
{
    void func()
    {
        OtherClass* pO = CreationPolicy<OtherClass>().Create();
    }
};

5. policy的优势

• 你可以从外部变更policies，就像策略模式一样，你可以随意替换policy.

• 你可以根据程序的需求设计你自己的policy，就像继承父类，实现父类提供的接口一样简单。

• 你还可以像函数参数的默认值一样指定最常用的policy

  template<template typename CreationPolicy = OpNewCreator>

6. 和虚函数的区别

​ 同样的，我们也可以使用虚函数实现这种创建，即继承重写虚函数实现这种工厂方法。正如上述所说，Policies是语法导向型，而classes是标记导向型。使用虚函数，覆写虚函数的函数签名完全一致，这就要求虚函数的传入的参数类型和数量是一致的。这对于类的构造函数多样性就失去了支持。另外一个的坏处是虚函数带来了虚表和指针的开销，增加了类对象的大小，在调用虚函数时增加了查找开销(多态要在运行期，才能确定最终的调用函数)。这些对于不带虚函数的模板类是没有的，可以省去的。模板同样对传入型别进行了约束，只是没有虚函数那样强烈，并且在编译时就完成了链接。虚函数也有好处，向上转型，我们可以实现多态调用。对于容器存储基类的指针以实现多个型别的存储，但是对于模板就不可以了，所以我们一般是结合两者使用。

7. 模板成员函数

​ 我们一直使用的是类模板，传入不同的型别构建不同的类，然后在调用Create()函数。有人就会想了，既然是每次传入类的型别不同，得到的结果也不同，这不是更像是函数的调用。我们直接使用模板成员函数即可(如下代码)，同时可以减小构建多个对象的开销，这样岂不是更好么？

struct OpNewCreator
{
	template<typename T>
	static T* Create()
	{
		return new T;
	}
};

// other similar

​ 这个时候OpNewCreator是一个非模板类(no-template class)，其内部有一个Create<T>()的模板函数。但是这种函数实在难以讨论和运作。首先，模板函数对于类型不做限制，给予用户以极大的操作空间而没有限制。当host继承这种类时，并没有给出函数的模板参数，在调用Create函数时编译器推断或者调用者明确指出类型T，并且继承host类同样不能对Create做出限制，这个权力在调用者，而不再设计者。其次，函数过程没有状态，或者其他可以供函数使用的信息。这就限制的函数实现的多样性，像PrototypeCreator这种存在依赖类型T的成员变量难以实现函数模板，从而失去了优势。但也不是完全没有办法，比如让函数传入更多的参数来获取更多信息(实现代码见下)。最后，这种各种类型T的Policy是一样的，这就相当于失去对类型优势，比如编译不做类型限制，这对与类的拓展和特化难以实现。

struct PrototypeCreator
{
	template<typename T, typename U>
    T* Create(U* pPrototype_)
    {
        return pPrototype_ ? pPrototype_->clone() : 0;
    }
}

8. Policy Classes的析构函数

​ 大部分情况下host class会以public继承从某些policies派生而来。因此，使用者可以向上转型，并delete该指针。

typedef WidgetManager<PrototypeCreator> MyWidgetManager;
MyWidgetManager wm;
PrototypeCreator<Widget>* pCreator = &wm;
delete pCteator; // compiles fine, but has undefined behavior

​ 这个错误是C++里面的一个常见错误。解决方法和我们的口诀一样简单，基类要定义一个虚析构函数。即policy class定义一个虚析构函数。然而，为policy定义虚析构函数，会妨碍policy的静态连接特性，也会影响执行效率，具体原因见和虚函数区别的讨论。但是很多情况下policies并无任何数据成员，纯粹只是规范行为。一个解法是，host class自policy host派生时，采用protected继承或private继承。这样又会因为接口为protected和private而失去丰富的policies特性。policies应该采用的解法是：定义一个protected的非虚析构函数，这时只有派生而来的类才能摧毁这个policy对象，这样外界就不可能delete一个指向policy class的指针，这也是这类问题的一般解法。

9. 通过不完全具现化获取选择机能

​ C++的有趣特性，造就了policies的丰富特性。如果class template有一个成员函数没有用到，它就不会被编译器具体实现出来。编译器不会理会，甚至不进行语法检验。这样就可以让host class有机会并使用policy class的可选特性。如下：

template<template<typename> typename CreationPolicy>
class WidgetManage:public CreationPolicy<Widget>
{
    void SwitchPrototype(Widget *pNewPrototype)
    {
        CreationPolicy<Widget> &myPolicy=*this;
        delete myPolicy.GetPrototype();
        myPolicy.SetPrototype(pNewPrototype);
    }
};

​ 如果你采用一个定义了SetPrototype()函数的Creator policy来实例化WidgetManager，就可以使用SwitchPrototype()函数。若采用不支持SetPrototype()函数的Creator policy来实例化WidgetManager，就会参数编译错误。如果你采用一个不支持SetPrototype()函数的Creator policy来实例化WidgetManager，如果使用过程中没有调用SwitchPrototype()，程序是合法的。

​ 这些都意味着WidgetManager除了可以从弹性且丰富的接口得到好处之外，也仍然可以搭配较为简单的接口而正常运作——只要你不试着去用其中某些成员函数，这提供了非凡的自由度和灵活性。

如果文章有用，欢迎点赞、打赏、转发。最重要的还是要谢谢大家的支持，我会一如既往地推送深度好文…

替精神支柱大猫仔化缘了，喵~