GP技术的展望——道生一，一生二

GP技术的展望——道生一，一生二

by 莫华枫

    长期以来，我们始终把GP（泛型编程）作为一种辅助技术，用于简化代码结构、提高开发效率。从某种程度上来讲，这种观念是对的。因为迄今为止，GP技术还只是一种编译期技术。只能在编译期发挥作用，一旦软件完成编译，成为可执行代码，便失去了利用GP的机会。对于现在的多数应用而言，运行时的多态能力显得尤为重要。而现有的GP无法在这个层面发挥作用，以至于我这个“GP迷”也不得不灰溜溜地声称“用OOP构建系统，用GP优化代码”。
    然而，不久前，在TopLanguage group上的一次讨论，促使我们注意到runtime GP这个概念。从中，我们看到了希望——使GP runtime化的希望——使得GP有望在运行时发挥其巨大的威力，进一步为软件的设计与开发带来更高的效率和更灵活的结构。
    在这个新的系列文章中，我试图运用runtime GP实现一些简单，但典型的案例，来检测runtime GP的能力和限制，同时也可以进一步探讨和展示这种技术的特性。

运行时多态

    现在的应用侧重于交互式的运作形式，要求软件在用户输入下作出响应。为了在这种情况下，软件的整体结构的优化，大量使用组件技术，使得软件成为“可组装” 的系统。而接口-实现分离的结构形式很好地实现了这个目标。多态在此中起到了关键性的作用。其中，以OOP为代表的“动多态”（也称为 “subtyping多态”），构建起在运行时可调控的可组装系统。GP作为“静多态”，运用泛化的类型体系，大大简化这种系统的构建，消除重复劳动。另外还有一种鲜为人知的多态形式，被《C++ Template》的作者David Vandevoorde和Nicolai M. Josuttis称为runtime unbound多态。而原来的“动多态”，即OOP多态，被细化为runtime bound多态；“静多态”，也就是模板，则被称为static unbound多态。
    不过这种称谓容易引起误解，主要就是unbound这个词上。在这里unbound和bound是指在编写代码时，一个symbol是否同一个具体的类型 bound。从这点来看，由于GP代码在编写之时，面向的是泛型，不是具体的类型，那么GP是unbound的。因为现有的GP是编译期的技术，所以是 static的。OOP的动多态则必须针对一个具体的类型编写代码，所以是bound的。但因为动多态可以在运行时确定真正的类型，所以是runtime 的。至于runtime unbound，以往只出现在动态语言中，比如SmallTalk、Python、Ruby，一种形象地称谓是“duck-typing”多态。关于多态的更完整的分类和介绍可以看这里。
    通过动态语言机制实现的runtime unbound，存在的性能和类型安全问题。但当我们将GP中的concept技术推广到runtime时会发现，rungime unbound可以拥有同OOP动多态相当的效率和类型安全性，但却具有更大的灵活性和更丰富的特性。关于这方面，我已经写过一篇文章 ，大致描述了一种实现runtime concept的途径（本文的附录里，我也给出了这种runtime concept实现的改进）。

Runtime Concept

    Runtime concept的实现并不会很复杂，基本上可以沿用OOP中的“虚表”技术，并且可以更加简单。真正复杂的部分是如何在语言层面表达出这种runtime GP，而不对已有的static GP和其他语言特性造成干扰。在这里，我首先建立一个基本的方案，然后通过一些案例对其进行检验，在发现问题后再做调整。
    考虑到runtime concept本身也是concept，那么沿用static concept的定义形式是不会有问题的：
      concept myconcept<T> {
          T& copy(T& lhs, T const& rhs);
          void T::fun();
          ...
      }
    具体的concept定义和使用规则，可以参考C++0x的concept提案或这篇文章 ，以及这篇文章 。
    另一方面，我们可以通过concept_map将符合一个concept的类型绑定到该concept之上：
      concept_map myconcept<MyType> {}
    相关内容也可参考上述文件。
    有了concept之后，我们便可以用它们约束一个模板：
      template <myconcept T> void myfun(T const& val); //函数模板

      template <myconcept T>
      class X  //类模板

      {
           ...
      };
    到此为止，runtime concept同static concept还是同一个事物。它们真正的分离在于使用。对于static concept应用，我们使用一个具体的类型在实例化（特化）一个模板：
      X<TypeA> x1;  //实例化一个类模板
      MyType obj1;
      myfun(obj1);  //编译器推导obj1对象的类型实例化函数模板
      myfun(obj1);  //函数模板的显式实例化
    现在，我们将允许一种非常规的做法，以使runtime concept成为可能：允许使用concept实例化一个模板，或定义一个对象。
      X<myconcept> x2;
      myconcept* obj2=new myconcept;
      myfun(obj2);  //此处，编译器将会生成runtime版本的myfun
    这里的含义非常明确：对于x2，接受任何符合myconcept的类型的对象。obj2是一个“动态对象”（这里将runtime concept引入的那种不知道真实类型，但符合某个concept的对象称为“动态对象”。而类型明确已知的对象成为“静态对象”），符合myconcept要求。至于实际的类型，随便，只要符合myconcept就行。
    这种情形非常类似于传统动多态的interface。但是，它们有着根本的差异。interface是一个具体的类型，并且要求类型通过继承这种形式实现这个接口。而concept则不是一种类型，而是一种“泛型”——具备某种特征的类型的抽象（或集合），不需要在类型创建时立刻与接口绑定。与 concept的绑定（concept_map）可以发生在任何时候。于是，runtime concept实际上成为了一种非侵入的接口。相比interface这种侵入型的接口，更加灵活便捷。
    通过这样一种做法，我们便可以获得一种能够在运行时工作的GP系统。
    在此基础上，为了便于后续案例展开