抠腚爱揉曼 Coding Iron Man

关于模板的一些有趣的东西（续）

模板类不会展开未引用的函数

一般情况下，下面的代码是不能通过编译的：

int FooFunc();

class FooClass
{
public:
    int FuncA() { return FooFunc(); }
    int FuncB() { return FooFunc(0); }
};

原因很简单，因为在FooClass::FuncB里面使用了未重载过的带一个参数的函数FooFunc。
但是如果换下面的形式：

template<typename>
class FooClass
{
public:
    int FuncA() { return FooFunc(); }
    int FuncB() { return FooFunc(0); }
};

void TestFunc()
{
    FooClass<void/*Could be any template parameter*/> obj;
    obj.FuncA();
}

这样的FooClass类是可以被编译，并且FooClass::FuncA是可以被正确调用的，哪怕他似乎包含了一个看上去就知道是错误的函数FooClass::FuncB。
但是如果换成下面的形式：

void TestFunc()
{
    FooClass<void/*Could be any template parameter*/> obj;
    obj.FuncB();
}

显式调用FooClass::FuncB是会触发编译错误的。因此我们似乎可以得出一种结论：模板类不会展开未引用的函数。
关于用例，我目前只是在实现能支持任意参数数量的模板函数器类里面用到过，暂时还想不到会被广泛使用的例子。

虚跟模板可以兼得？！（续）

模板不可用

有种项目开发模式叫做模块式开发，简而言之就是将项目功能分隔成一个个独立的模块，然后每个模块提供预先商定好的接口以便各模块之间的通信。往往在这种模式下面，接口都是通过纯虚的方法定义的，所以在这种开发模式下面，模板是不可用的。

（伪）灵活调用接口

模板提供的方便之处之一便在于调用时可以了传递任意类型的数据而不需要分别针对性的实现。但是在模块接口式开发的模式下面，自然不能直接定义模板化接口。目前来说，我能想到的就是手动重载函数的针对各种可接受类型的版本，然后同样他们都需要被虚化。例如：

class FooInterface
{
    virtual void FooFunc(const char& value) = 0;
    virtual void FooFunc(const int& value) = 0;
    virtual void FooFunc(const long& value) = 0;
    virtual void FooFunc(const float& value) = 0;
}

（伪）结合模板与虚函数

其实这也不是一种很优雅的解决方式，简单来说就是通过模板将任意类型都映射到那些手动定义的虚方法上面。例如：

class FooInterface
{
    template<typename ValueType>
    void FooFunc(const ValueType& value)
    {
        FooFunc(ToCompatibleValueType(value));
    }
    virtual void FooFunc(const char& value) = 0;
    virtual void FooFunc(const int& value) = 0;
    virtual void FooFunc(const long& value) = 0;
    virtual void FooFunc(const float& value) = 0;
}

这样一来你就可以将任意类型的参数传递给这个FooFunc而无需修改添加多余的虚方法的声明定义。但是前提是这里面的ToCompatibleValueType函数能够将你提供的这些任意类型的参数给映射成那些已经被手动重载的版本。

意义何在？

当手动重载的FooFunc函数版本有限，而调用的地方又很多，原始参数类型也多种多样的时候，因为FooFunc这个接口本身是虚的不能模板化，我们不得不面对大量各种类型转换的调用。而通过这个多出来的模板化的FooFunc，我们可以在ToCompatibleValueType里面对所有类型做集中的类型转换（当然这里会用到很多的Meta Programming以及模板偏特化等等）。而在我们调用该方法的地方则可以传递任意类型数据给该函数，看上去便会有类似模板函数那样方便的效果。
ToCompatibleValueType就像是一个过滤器一样，尝试将任意类型转换为可兼容那些手动指定的数据类型，当然如果发现有些类型无法转换的时候，触发一个编译期的错误提醒开发人员也是很有作用的。

关于脚本

一些关于脚本的琐碎的思绪。

如果说Programming Language是对应基础框架以及底层兼容的偏硬性问题的解决方案，那Script Language便是某种意义上真正面向应用功能的解决方案。Programming Language的初衷是调用平台的各种资源与功能，为了达到最好的效果往往都是贴近底层开发的，在这方面“硬”的东西比较多，而且一旦敲定，便不会容易修改。简而言之，Hardcode大概就是这样一种意思。

太硬的东西无论是开发者还是客户都所不愿意见到的，他们不希望自己买了一辆自行车，轮子只能转到100圈，除非他们都是2B。

于是乎有一种叫Data Driven的概念出现了。大约来讲它属于已经被Hardcode编译成计算机本地指令的程序的外部配置信息。程序的代码已经实现了开发过程中能够预见的大多数功能，这些功能可以接收一定的可变的参数来达到一定程度的“动态性”。这基本上是目前绝大多数项目的一种比较统一的解决方案，无论是application，service或者game。

这种开发模式有一个比较重要的平衡点需要掌握：我们需要将多少功能给做出来，又需要将多少功能可以进行外部的配置。前者过多就会导致过多的硬编码，而后者过多就会导致过于零散的功能以及过于复杂的配置。

无论如何，硬编码是我们是在不想看到的，但是如果功能做得过于原子化，那外部的配置必然会相当复杂。要知道在一个团队里面，负责这部分数据生产的不一定都是城续猿。

有时候我们不能太明白的说明，我们到底想要一个什么样具体的功能，城续猿没办法做出一个抽象的模棱两可的功能然后再暴露一些有限的参数供团队里面其他成员使用，而后者往往也说不清楚自己到底想要什么样的东西。但就算双方能达成协议，通过修改代码来实现新功能以及调试的代价往往也是比较昂贵的。

那么，为何不让他们自己去做？

于是我们需要一种，简单，可用，且能比较高效开发的方式 —— 脚本。

理论上来讲脚本也是一种编码语言，它同样有分支，有循环，有变量，只不过其所在的层次不一样。脚本其实也是Data Driven里面的数据，只不过与单纯的贴图，动画，音效等纯数据相比它更有一种自我描述性。换言之它们能自己说明自己的目的，而不是简单的被贴到某个设置好了UV的模型上面去。

城续猿可以做好一系列的相对独立的功能，这些功能之间可以拼凑组合，相互调用，往往我们会将它们称之为API，最终它们会暴露给脚本使用。

在此基础上，如果说通过Programming Language实现的框架模型是“第一次开发”，那么通过Script Language我们可以在项目中进行“第二次开发”。这也就是一种理想的“准备阶段”往“生产阶段”过渡的方式。案例例如游戏中各种角色的AI，任务，界面UI等等。

待续…