C++博客-qiezi的学习园地-随笔分类-asgard项目

为C＋＋实现一个IDL　（五）

qiezi — Wed, 28 Sep 2005 14:57:00 GMT

本篇没什么清晰的目的，只是解释一下前面的几个问题，并提出一些新的目标。

在“asgard项目遗留问题”中，我简单提到了几个问题，并且想了一些解决方案。

其中，最首要解决的是第2条“服务对象的大小”和第5条“全局元信息”，这2条将影响到调用机制、call对象的生成。一个调用将生成一个call对象，由线程池来处理，同步调用将由异步调用来模拟。

在call对象中，保存了所有in/out参数的包装对象。当处理同步调用时，由于out参数可能是一个栈上对象（或简单类型，这里统称对象），所以需要另一个包装类——outret模板类，它保存out参数的引用。

当同步调用发生时，生成一个call对象（当然out参数的引用已经包含在里面），把这个call对象交给线程池处理，调用的线程阻塞等待调用结束后被唤醒，这就是所谓的异步调用模拟同步调用。由于异步调用被包装起来了，所以在调用者看来跟同步调用没什么区别。当然这个动作并非必要，完全可以不使用模拟，而采用真正的同步调用，只是看到ICE是这么实现的，心痒痒而已。

asgard的目标是把现有的系统功能包装成为服务，所以在通用方面我考虑得比较多。

比如服务端要开放下面这样一个服务：

service StringService
{
Method <string(inout<string>, in<string>)> strcat;
Method <string(inout<string>, in<string>, in<uint>)> strncat;
};

并且把C标准库中的strcat和strncat作为这2个方法的实现。

看一下存在哪些问题？

1、函数第1个参数如果直接映射为string，在服务端将出现缓冲区溢出。

2、C标准库中的strcat返回值是一个指针，它指向strcat的第一个参数（搞这个标准库的人是不是没想过这个返回值多么没用啊？？直接返回一个操作的长度不是更好？），在服务端发回客户端时，这个并不需要被发回来，因为strcat的第1个参数已经能带回操作后的内容了。

3、strncat的第3个参数表示第1个缓冲区参数的长度，如果能把它和第1个参数合起来用一个buffer对象表示，就能省事了。

理想情况下，我们的服务对象这样来写：

service StringService
{
Method <void(inout< buffer<char> >, in<string>)> strcat;
Method <void(inout< buffer<char> >, in<string>)> strncat;
};

我们的目的是把老的代码包装成新鲜时髦的服务，当然不用保留老式代码中的指针，以及使用指针和长度2个值来表示一个缓冲区的做法。buffer类在构造时要接受一个size_t参数，指定缓冲区的大小。

这在服务端将产生映射问题，由于这个Method定义的形式和C标准库中的函数形式不一致。

我想应该去实现一个适配器模板类，比如：

this->strcat.setFunction (adapter<char*(char*, const char*), convert<void, 0>(inout< buffer<char> >, in<string>)> (::strcat));

this->strncat.setFunction (adapter<char*(char*, const char*, size_t), convert<void, 0>(inout< buffer<char> >, in<string>, length<in<uint>, 1>)> (::strncat));

convert表示把第0个参数（这里指返回值）转成void类型，length, 1>表示这个参数类型是int，它是从第1个参数中提取的长度，大致就是使用这种规则，语法可能以后会有变动。

这点内容是我几个月前就在考虑的，也是我想做这个项目的动机，不过直到最近一段时间才从可行性方面仔细考虑。

通过前面几个模板的练习，现在已经大致知道哪些东西是可以用模板做出来，哪些不能使用模板，这应该是最大的收获了。很多东西单靠模板或是虚函数都不好完成，但结合起来就能产生意想不到的效果。

又仔细想了一下，上面的代码应该还可以修改简化：

this->strcat.setFunction (adapter<convert<void, 0>(inout< buffer<char> >, in<string>)> ( ) (::strcat));

this->strncat.setFunction (adapter<convert<void, 0>(inout< buffer<char> >, in<string>, length<in<uint>, 1>)> ( ) (::strncat));

使用一个仿函数来做，函数指针的类型可以从operator ()的参数（模板参数）中推导出来。

qiezi 2005-09-28 22:57 发表评论

asgard项目遗留问题　（2005-09-27更新）

qiezi — Sat, 24 Sep 2005 09:00:00 GMT

asgard项目已经准备了一段时间了，不过有些基本问题还需要考虑，也有一些是新发现的问题，以及自认为比较好的解决办法。

通过第2、第4条的仔细研究，已经渐渐完善、明确了动态部分和静态部分的关系，使得Method包装类所完成的功能渐渐接近于一个函数，而元信息则脱离具体的对象提升到全局（当然还有些小问题没有解决）。

1、参数名称的问题。

为了与SOAP等基于XML的协议兼容，必须开始就把参数名称考虑在内。

代码经过C＋＋编译器编译以后，类型、变量名称等都不复存在，唯一留下的是RTTI，显然不能解决这个问题。所以只能在定义时把它加入。

BEGIN_SERVICE(TestService)
METHOD (void(in<int>, inout<string>, out<short>), method1, index, info, result);
END_SERVICE()

如果使用这种方式，index, info, result分别表示变量名字，在宏里面转成字符串，看起来好像不太舒服，而且宏不支持参数个数变化。

BEGIN_SERVICE(TestService)
METHOD (void(in<int>, inout<string>, out<short>), method1, "(index, info, result)");
METHOD (int(in<int>, inout<string>), method2, "result(index, info)");
END_SERVICE()

这种可能稍稍舒服一点，在Method构造函数或其它地方解析这个字符串，赋给各个参数。不过它的缺点是把编译期应该检查出来的错误，延迟到运行期。如果在编译期来做，又会使接口描述变得很复杂。

只是为了得到参数的名字，就要增加这么些麻烦。

c++0x只是一个库的标准，估计XTI也不会加入这些特性，而且c++0x很遥远，所以暂时以这种方式来做。

暂时的解决办法：

BEGIN_SERVICE(TestService)
    METHOD (void(in<int>, inout<string>, out<short>), method1);
    METHOD (int(in<int>, inout<string>), method2);
    BEGIN_SERVICE_DEFINE(TestService)
        METHOD_DEFINE (method1, "(index, info, result)", test_func);
        METHOD_DEFINE (method2, "result(index, info)", &Test::test_method);
    END_SERVICE_DEFINE()
END_SERVICE()

缺点是参数名称中的错误，要延迟到运行期才能解决掉。

2、服务对象的大小。

如果客户端要调用其中一个方法，生成一个TestService，则构造成本太高，特别是一个服务中有多个方法的时候。一个服务容纳了多个方法，而每个方法包含一个vector，以及各个参数，这还没考虑以后的扩展。

所以应该修改调用方式，让它只只需要生成调用所需的最小（少）对象。

这部分考虑还不成熟，暂时可以不管它，而以方法作为考虑的对象。

暂时想到的解决办法：

Method对象中的parameters容器和各个参数，只在调用operator ()或async_call时，才真正生成出来。

这样的话，Method对象中仅保存一个空的vector。

甚至这个vector也可以只是一个空指针，当调用那几个函数时，才生成一个。

暂时把这个过程命名为Create On Call(COC)。

COC的好处是显而易见的，每个对象将只有8字节，虚表指针＋数据对象的指针，“数据对象”是实际调用时才生成的对象，包括参数vector容器、回调函数指针（可能由动态生成一个委托对象，以适应广泛类型的回调函数）、对象锁（防止干扰到前一个调用）。初始化成本接近0（虚函数表的初始化忽略不计）。

当调用operator()或async_call时（以下简称CALL），将调用create_parameters虚函数，动态生成一个vector。这样，没有调用到的Method不会象原来一样影响到服务对象的构建性能。

这就要求把Method的“元”信息提到全局，当然更符合“元”的本意，原来由服务对象查询Method以获得“元”信息的过程，现在看来也是不合理的。

3、in模板可以省略。

in是默认的参数类型，返回值则默认为out类型，这都是不需要明确指定的。

解决办法：

这个问题是比较好解决的，在InOutTypeTraits模板类中，为各个偏特化版本定义一个type类型，InOutTypeTraits＜T＞::type的类型为in＜T＞，InOutTypes＜in＜T＞＞::type的类型为in＜T＞，InOutTypes＜inout＜T＞＞::type的类型为inout＜T＞，InOutTypes＜out＜T＞＞::type的类型为out＜T＞，InList模板类中进行这种转换。

4、异步调用队列。

在第2点中介绍道：

每个对象将只有8字节，虚表指针＋数据对象的指针，“数据对象”是实际调用时才生成的对象，包括参数vector容器、回调函数指针（可能由动态生成一个委托对象，以适应广泛类型的回调函数）、对象锁（防止干扰到前一个调用）。初始化成本接近0（虚函数表的初始化忽略不计）。

提到了对象锁，这是一种低效的做法，可以使用异步调用队列来替代它。

解决办法：

当开始一个调用时，临时生成上面所说的“数据对象”，交由一个调用队列去完成。这时，由于Method对象基本不管理数据，所以它成了一个空壳，作用是保存类型信息。

异步调用最好的实现就是整个系统都由异步调用构成，而同步调用是由异步调用模拟而成。原本打算绕过这种方式，用最简单的方法来做，现在好像又绕回来了。

上面这个做法，很好地把元信息和真实数据分开了，所以打算改成这种结构。

5、全局元信息。

通过第4条的研究，已经使得Method对象成为一个空壳，而“数据对象”在没有调用时又不生成，使得自省结构必须重新做。

考察了java等语言的自省，也打算把元信息的位置提升到全局，而每个Method对象将只保留一个全局元信息的指针，这样应该更自然。

（以后遇到的问题只更新到这个文档中）

qiezi 2005-09-24 17:00 发表评论

为C＋＋实现一个IDL　（四）

qiezi — Thu, 22 Sep 2005 11:13:00 GMT

如《为C＋＋实现一个IDL（三）》一文中所说，还剩最后一个问题，还是使用前面的测试代码说明。

async_call函数的原型是：

typedef void(*FUNC_TYPE)(int, char, string, short);

void async_call (int v0, char v1, string v2, FUNC_TYPE func);

这是模板类根据in/out来产生的。

在异步调用中，参数是和操作保存在一起的，因为要交给线程处理。前面已经说过，Method模板类中将保有这些参数，Method的定义如下（以例子中4个参数的特化版本来说明）：

template <class A, class B, class C, class D>
struct Method <void(A,B,C,D)> : public Base < typename Loki::TL::MakeTypelist< A,B,C,D >::Result >
{
    A a;
    B b;
    C c;
    D d;
    Method ()
    {
        parameters.push_back (&a);
        parameters.push_back (&b);
        parameters.push_back (&c);
        parameters.push_back (&d);
    }
};

相应地，Base类使用这个特化版本：

template <class TYPES, class IN_TYPES>
struct Base <TYPES, IN_TYPES, 3> : public IMethod
{
    typedef typename FuncTypeTraits <TYPES>::Result FUNC_TYPE;

    void async_call (
        typename Loki::TL::TypeAt <IN_TYPES, 0>::Result::OriginalType v0,
        typename Loki::TL::TypeAt <IN_TYPES, 1>::Result::OriginalType v1,
        typename Loki::TL::TypeAt <IN_TYPES, 2>::Result::OriginalType v2,
        FUNC_TYPE func = 0)
    {
    }
};

TYPES模板参数中保存了所有的参数类型，IN_TYPES模板参数中保存了所有的in参数类型，但它们不知道如何来对应起来，async_call也不知道如何把几个参数值交给parameters（在IMethod中定义，见上一篇）。

如果我们在生成IN_TYPES的时候，把它在TYPES中的位置（索引）也一起交给它，就能解决这个问题。

InList第二个模板参数是一个常量，当我们把TYPES交给它时，以上面的代码为例，将会使用T_COUNT值为4的偏特化版本。这时候，将会首先推导出IN_TYPES中的第一个类型int，它在IN_TYPES中的索引是0，并接着调用T_COUNT值是3的偏特化版本，这样递归推导，直到调用T_COUNT值为0的偏特化版本，这个过程就结束了。在这个递归过程中，能够得到各个类型以及对应的“索引”值：int: 4, char: 3, string: 2。

注意这个索引值和实际的索引值是有差别的，实际的索引值应该是4-T_COUNT，所以上面的对应关系应该是：int: 0, char: 1, string: 2。

最初传递给InList的TYPES有4个元素，当它递归调用时，这个值就会依次递减，后面的递归调用并不知道应该用4去减掉T_COUNT作为索引，因为4并没有传递过来。简单的解决办法是再加上一个模板参数，让它往下传递，当然这种方式并不好看，好在我们不是真的必须这么做。

注意，在Base类中，它是知道TYPES的个数的，那么只要用这个数减去前面生成的IN_TYPE的“索引”，就能得到这个类型在TYPES中的真正索引。（这部分真是有点罗嗦）

修改InList模板类，让它生成由 [ in类型以及in类型在TYPES中的“索引”] 构成的新Typelist。

首先要增加一个辅助模板类：

template <class T, int INDEX>
struct TypeReversedIndex
{
typedef T type;
enum {value = INDEX};
};

它能够保存一个类型，以及一个整数。取名为TypeReversedIndex，意思是说它要保存一个Type和一个ReversedIndex（反的索引）。

InList模板类也要修改，OutList依旧是免费赠送：

template < class T, int T_COUNT = Loki::TL::Length <T>::value >
struct InList
{
    typedef typename If <
        InOutTypeTraits <typename T::Head>::isin,
        typename Loki::Typelist < TypeReversedIndex <typename T::Head, T_COUNT>, typename InList <typename T::Tail>::Result >,
        typename InList <typename T::Tail>::Result
    >::Result Result;
};

template <class T>
struct InList < T, 0 >
{
    typedef typename Loki::TL::MakeTypelist <>::Result Result;
};

template < class T, int T_COUNT = Loki::TL::Length <T>::value >
struct OutList
{
    typedef typename If <
        InOutTypeTraits <typename T::Head>::isout,
        typename Loki::Typelist < TypeReversedIndex <typename T::Head, T_COUNT>, typename OutList <typename T::Tail>::Result >,
        typename OutList <typename T::Tail>::Result
    >::Result Result;
};

template <class T>
struct OutList < T, 0 >
{
    typedef typename Loki::TL::MakeTypelist <>::Result Result;
};

Base类就可以写出来了：

template <class TYPES, class IN_TYPES>
struct Base <TYPES, IN_TYPES, 3> : public IMethod
{
    typedef typename FuncTypeTraits <TYPES>::Result FUNC_TYPE;
    typedef IN_TYPES type;

    enum {TYPES_COUNT = typename Loki::TL::Length<TYPES>::value};

    void async_call (
        typename Loki::TL::TypeAt <IN_TYPES, 0>::Result::type::OriginalType v0,
        typename Loki::TL::TypeAt <IN_TYPES, 1>::Result::type::OriginalType v1,
        typename Loki::TL::TypeAt <IN_TYPES, 2>::Result::type::OriginalType v2,
        FUNC_TYPE func = 0)
    {
        ((typename Loki::TL::TypeAt <IN_TYPES, 0>::Result::type*)
            parameters[TYPES_COUNT - typename Loki::TL::TypeAt <IN_TYPES, 0>::Result::value])->setValue (v0);
        ((typename Loki::TL::TypeAt <IN_TYPES, 1>::Result::type*)
            parameters[TYPES_COUNT - typename Loki::TL::TypeAt <IN_TYPES, 1>::Result::value])->setValue (v1);
        ((typename Loki::TL::TypeAt <IN_TYPES, 2>::Result::type*)
            parameters[TYPES_COUNT - typename Loki::TL::TypeAt <IN_TYPES, 2>::Result::value])->setValue (v2);
    }
};

parameters中存放的是IParameter*类型，这里使用了强制转型，并调用in/inout模板类的setValue方法给它赋值。

为了测试结果，我为IParameter加上了void print () const虚函数，并在in/inout/out模板类中实现它，打印出类型，in/inout类中还将打印出参数值。

class IParameter
{
public:
virtual void print () const = 0;
};

template <class T>
struct in : public IParameter
{
    typedef T OriginalType;
    T value;
    void setValue (T v){
        value = v;
    }
    void print () const {
        cout << typeid(*this).name() << ": " << value << endl;
    }
};

template <class T>
struct out : public IParameter
{
    typedef T OriginalType;
    virtual void print () const {
        cout << typeid(*this).name() << endl;
    }
};

template <class T>
struct inout : public IParameter
{
    typedef T OriginalType;
    T value;
    void setValue (T v){
        value = v;
    }
    virtual void print () const {
        cout << typeid(*this).name() << ": " << value << endl;
    }
};

并在Base::async_call中调用parameters中所有对象的print函数来输出一些调试信息：

for (size_t i = 0; i < parameters.size(); i ++)
parameters[i]->print ();

简单测试了2种类型，不能保证所有代码都是正确的，毕竟是手工写出来的也没经过检查，模板类在没有实例化的时候某些错误是不会报告的。

测试代码如下：

void test_func (int v0, char v1, string v2, short v3)
{
    cout << "===========================================" << endl;
    cout << "test_func(" << v0 << ", " << v1 << ", " << v2 << ", " << v3 << ")" << endl;
}

void test_func1 (int v0, char v1, short v2, string v3)
{
    cout << "===========================================" << endl;
    cout << "test_func1(" << v0 << ", " << v1 << ", " << v2 << ", " << v3 << ")" << endl;
}

int main()
{
    {
        Method < void(in<int>, in<char>, inout<string>, out<short>) > m;

        m.async_call(3, 'a', "test");
        cout << "===========================================" << endl;
        m.async_call(3, 'a', "test", test_func);
        cout << "===========================================" << endl;
    }

    {
        Method <string(in<int>, out<char>, inout<short>)> m;
        m.async_call(3, 4);
        cout << "===========================================" << endl;
        m.async_call(3, 4, test_func1);
        cout << "===========================================" << endl;
    }

    return 0;
}

全部代码太长，就不一一罗列于此了，可以点击这里下载。

qiezi 2005-09-22 19:13 发表评论

为C＋＋实现一个IDL　（三）

qiezi — Wed, 21 Sep 2005 12:34:00 GMT

摘要: 一、修正错误。首先修正第二篇中的一些错误，错误的内容可见第二篇的评论。在Base类中，FUNC_TYPE需要所有的in/out类型，如果Method的模板参数——即函数类型参数——的返回值不是void，则把它装配成out参数，作为FUNC_TYPE函数类型的最后一个参数，这可以通过偏特化来实现。修改Method模板类，把所有类型包装成一个Typelist，直接传递给Base模板类，由Base去推导... 阅读全文

qiezi 2005-09-21 20:34 发表评论

为C＋＋实现一个IDL　（二）

qiezi — Tue, 20 Sep 2005 14:34:00 GMT

说明：
要看懂后面那部分代码，即使用Typelist的部分，最好预先看过《C＋＋设计新思维》，英文版名为《Modern C++ Design》。
If模板类在写完后想起来好像在哪见过，早晨去公司查阅了一下，在《产生式编程——方法、工具与应用》一书中有讲，英文名为《Generative Programming -- Methods, Tools, and Applications》基本和本篇中一个样。

前2篇乱七八糟地讲了一些，有一个遗留问题，函数原型的推导。

简要描述如下：

Method < void(in<int>, in<char>, inout<string>, out<short>) > method;

// 同步调用
string str = "hello";
short value = 2;
method (3, 'a', str, value);

// 异步调用1
method.async_call (3, 'a', "hello");

// 异步调用2
void test_func (int, char, string, short);
method.async_call (3, 'a', "hello", test_func);

要产生这3种函数形式。参数类型如何转换，是以后的话题，本篇主要解决异步调用的函数原形推导问题。本篇也不讨论Method的模板参数（即那个函数类型）返回类型不为void的情况。

第一种形式，同步调用，比较好处理，参数个数和模板参数的数量相同。

后2种形式，如何让编译器根据in/out来推导出函数原型？

我们需要编译器做这样的处理，async_call的参数类型中，in类型的参数将保留，out类型的参数不需要，inout类型也需要保留。

要用到的Loki头文件：

#include <static_check.h>
#include <Typelist.h>

using namespace Loki;
using namespace Loki::TL;

首先看看in/inout/out的声明。为了简化，这里去掉了跟类型推导无关的部分。

class NullType
{
    NullType ();
};

template <class T>
struct in
{
    typedef T OriginalType;
};

template <class T>
struct out
{
    typedef T OriginalType;
};

template <class T>
struct inout
{
    typedef T OriginalType;
};

下面Method模板类的声明，使用偏特化来产生代码。为了简化，我只取函数参数个数为4个参数的版本，比照着上面的代码来解释，只解释method.async_call (3, 'a', "hello", test_func);这个版本，因为另一个比它简单。

template <class T>
struct Method
{
};

template <class Ret, class A, class B, class C, class D>
struct Method <Ret(A,B,C,D)>
{
};

根据上面Method的定义，Method < void(in, in, inout, out) > ，async_call函数的类型将是：

typedef void (*FUNC_TYPE)(int, char, string, short);
void async_call (int, char, string, FUNC_TYPE func);

实际上FUNC_TYPE应该能够接受更广泛的类型，比如void(int, char, char*, short)，这可以在内部做一些转换，不过本篇的重点不在这里，所以只讲上面的那种形式。

直接在Method类中实现有些麻烦，所以我把这个函数放在一个基类中实现，只要编译器能帮我们推导出下面这种形式就行了：

template <class Ret, class A, class B, class C, class D>
struct Method <Ret(A,B,C,D)> : public Base < A, B, C >
{
};

注意，这里是以Method < void(in, in, inout, out) >这种形式来讲的，才会有上面那种继承关系。而实际上，由于in/out在参数中的位置、数量都是未知的，要到定义时才能确定，所以使用模板来推导。（入正题了）

也就是说，只要我们能使用静态推导方式，获得A,B,C,D这四个参数中所有的in类型，把它交给Base作为模板参数就成了。

这里需要一个辅助的模板类，用来在编译时帮助推导：

template <class T>
class InOutTypeTraits
{
    Loki::CompileTimeError <false> Not_Supported_Type;
};

template <class T>
struct InOutTypeTraits < in<T> >
{
    enum {isin=1, isout=0};
};

template <class T>
struct InOutTypeTraits < out<T> >
{
    enum {isin=0, isout=1};
};

template <class T>
struct InOutTypeTraits < inout<T> >
{
    enum {isin=1, isout=1};
};

template <>
struct InOutTypeTraits < NullType >
{
    enum {isin=0, isout=0};
};

通过另一个模板类InList来帮我们产生所有的in类型，它的结果是一个Typelist。为了方便以后使用，我把out类型产生器也做了一个OutList。

template <int CONDITION, class _IF, class _ELSE>
struct If
{
    typedef _IF Result;
};

template <class _IF, class _ELSE>
struct If <0, _IF, _ELSE>
{
    typedef _ELSE Result;
};

template <class A = NullType, class B = NullType, class C = NullType, class D = NullType,
    class E = NullType, class F = NullType, class G = NullType, class H = NullType
>
struct InList
{
    typedef typename If <
        InOutTypeTraits <A>::isin,
        typename Typelist < A, typename InList<B,C,D,E,F,G>::Result >,
        typename InList<B,C,D,E,F,G,H>::Result
    >::Result Result;
};

template <class A>
struct InList <A, NullType, NullType, NullType, NullType, NullType, NullType, NullType>
{
    typedef typename If <
        InOutTypeTraits <A>::isin,
        typename MakeTypelist <A>::Result,
        typename MakeTypelist <>::Result
    >::Result Result;
};

template <class A = NullType, class B = NullType, class C = NullType, class D = NullType,
    class E = NullType, class F = NullType, class G = NullType, class H = NullType
>
struct OutList
{
    typedef typename If <
        InOutTypeTraits<A>::isout,
        typename Typelist < A, typename OutList<B,C,D,E,F,G>::Result >,
        typename OutList<B,C,D,E,F,G,H>::Result
    >::Result Result;
};

template <class A>
struct OutList <A, NullType, NullType, NullType, NullType, NullType, NullType, NullType>
{
    typedef typename MakeTypelist <A>::Result Result;
};

它的原理是，根据If模板类来判断一个类型是不是in类型，是的话就把它加入到Typelist中，不是就排除它。

InList , in, inout, out::Result是一个Typelist , Typelist, Typelist, NullType> > >类型，说简单点，它和MakeTypelist < in, in, inout >::Result是等价的。

现在Base模板类将接受一个模板参数，它是一个Typelist类型，这个不详细讲了，把它的定义写出来：

template <class T, int T_COUNT = Length <IN_TYPE>::value >
struct Base
{
    Loki::CompileTimeError <false> Only_Use_Partial_Specialisation_Version;
};

template <class T>
struct Base <T, 0>
{
    typedef void(*FUNC_TYPE)();

    template <class FUNC_TYPE>
    void async_call (FUNC_TYPE func)
    {
    }
    void async_call ()
    {
    }
};

template <class T>
struct Base <T, 1>
{
    typedef void(*FUNC_TYPE)(
        typename TypeAt <T, 0>::Result::OriginalType);

    void async_call (
        typename TypeAt <T, 0>::Result::OriginalType v0,
        FUNC_TYPE func)
    {
    }
    void async_call (typename TypeAt <T, 0>::Result::OriginalType v0)
    {
    }
};

template <class T>
struct Base <T, 2>
{
    typedef void(*FUNC_TYPE)(
        typename TypeAt <T, 0>::Result::OriginalType,
        typename TypeAt <T, 1>::Result::OriginalType);

    void async_call (
        typename TypeAt <T, 0>::Result::OriginalType v0,
        typename TypeAt <T, 1>::Result::OriginalType v1,
        FUNC_TYPE func)
    {
    }
    void async_call (
        typename TypeAt <T, 0>::Result::OriginalType v0,
        typename TypeAt <T, 1>::Result::OriginalType v1)
    {
    }
};

template <class T>
struct Base <T, 3>
{
    typedef void(*FUNC_TYPE)(
        typename TypeAt <T, 0>::Result::OriginalType,
        typename TypeAt <T, 1>::Result::OriginalType,
        typename TypeAt <T, 2>::Result::OriginalType);

    void async_call (
        typename TypeAt <T, 0>::Result::OriginalType v0,
        typename TypeAt <T, 1>::Result::OriginalType v1,
        typename TypeAt <T, 2>::Result::OriginalType v2,
        FUNC_TYPE func)
    {
    }
    void async_call (
        typename TypeAt <T, 0>::Result::OriginalType v0,
        typename TypeAt <T, 1>::Result::OriginalType v1,
        typename TypeAt <T, 2>::Result::OriginalType v2)
    {
    }
};

template <class T>
struct Base <T, 4>
{
    typedef void(*FUNC_TYPE)(
        typename TypeAt <T, 0>::Result::OriginalType,
        typename TypeAt <T, 1>::Result::OriginalType,
        typename TypeAt <T, 2>::Result::OriginalType,
        typename TypeAt <T, 3>::Result::OriginalType);

    void async_call (
        typename TypeAt <T, 0>::Result::OriginalType v0,
        typename TypeAt <T, 1>::Result::OriginalType v1,
        typename TypeAt <T, 2>::Result::OriginalType v2,
        typename TypeAt <T, 3>::Result::OriginalType v3,
        FUNC_TYPE func)
    {
    }
    void async_call (
        typename TypeAt <T, 0>::Result::OriginalType v0,
        typename TypeAt <T, 1>::Result::OriginalType v1,
        typename TypeAt <T, 2>::Result::OriginalType v2,
        typename TypeAt <T, 3>::Result::OriginalType v3)
    {
    }
};

这部分有点多，其实还是比较清晰的。注意这个Base的版本已经不是上面所讲的那个了。

函数原形推导问题就讲完了。上面的代码不一定还能编译，昨天是能编译的，被我修改了一些，为了解释，又改成昨天那样子。

qiezi 2005-09-20 22:34 发表评论

为C＋＋实现一个IDL　（一）

qiezi — Sat, 17 Sep 2005 11:40:00 GMT

前面简单写了点静态结构，这一次将主要关注动态模型以及调用方式。

这个系列的名字叫“为C++实现一个IDL”，实际上应该叫“为C++实现一个Remoting”可能更好一些，说是IDL，主要是想通过宏，使用简单的类型定义达到自动生成调用代码的目的。

一、首先来看看调用习惯。

从调用习惯入手，主要是因为看到目前有很多库/工具包在调用上都有很多不便之处。假如能在一开始就从这点出发，就能把调用接口设计得更好一些。

先来看看服务端如何开放一个服务。

int main ()
{
    // 发布为SOAP服务，先生成一个服务容器。
    // 服务将发布在localhost的7911上，localhost用来绑定loopback网卡。
    SOAPProxy soap_service (7911, “localhost”);

    TestService test_service;
    soap_service.addService  (“test_service”, &test_service);

    TestService service1;
    soap_service.addService (“HelloService”, &service1);

    try{
        soap_service.run ();
    } catch (SocketException& e)
    {
    } catch (SignalException& e)
    {
    }

    return 0;
}

我希望就是这么简单，客户端调用有多种方式：
1、使用服务的IDL定义，直接调用：

int main ()
{
    SOAPProxy soap_service (7911, “localhost”);

    try{
        TestService test_service (“test_service”, &soap_service);
        test_service.method1 (/**/);
    } catch (SocketException& e)
    {
    }
    return 0;
}

这种方式比较简单，调用时会检查是否已经连接，然后发送调用请求，并处理调用结果。

2、服务验证方式：

int main ()
{
    SOAPProxy soap_service (7911, “localhost”);
    TestService test_service;
    soap_service.getService (“test_service”, &test_service);

    if (test_service)
    {
        try{
            test_service.method1 (/**/);
        } catch (SocketException& e)
        {
        }
    }
    return 0;
}

3、服务发现方式：

int main ()
{
    SOAPProxy soap_service (7911, “localhost”);
    vector <string> services_name = soap_service.getServiceNames ();
    //
    IService* test_service = soap_service.getService (“test_service”);
    if (test_service)
    {
        vector <string> methods = test_service->getMethodNames ();
        IMethod* method = test_service->getMethod (“method1”);
        vector <Type*> types = method->getParameterType s()
        method->addArg (3);
        method->addArg (4);
        //
        method->invoke ();
        //
    }
    return 0;
}

二、基本需求。

简单分析一下，上面一共涉及了哪些类型？
IProxy:
这是所有Proxy类的基类(和接口)，它可以容纳多个服务对象，提供服务绑定、服务查询、服务发现、服务验证。
IService:
所有Service类的基类，可以容纳多个方法(Method)，提供方法查询、服务验证。
IMethod:
所有Method模板类的基类，容纳多个参数，包括返回值，可通过查询参数类型获得方法的类型定义。
IParameter:
所有参数的基类，包含一个参数类型描述和一个参数值。
IType:
所有类型的基类，预定义了一些基本类型，可自定义类型。

看起来挺多的，其实很难接触到这些，只需要使用宏来定义一个服务，就可以通过模板的类型推导，自动生成这些复杂的定义。

三、调用过程。

以下只简单分析一下同步调用，异步调用将是以后的扩充话题。
根据第二节的3种不同调用过程，简要描述如下：

直接调用。
- 生成SOAPProxy，让它连接到远程主机。
- 生成一个TestService对象，设置远程主机上的服务名称，并指定使用SOAPProxy，也即使用SOAP协议。
- 调用TestService::method1方法。根据method1的定义，把服务名称、方法名称、各个in参数等打包成一个“集合”，交给SOAPProxy处理。
- SOAPProxy把这个“集合”转换成SOAP消息，发送到远程主机，阻塞线程。
- 远程主机上的SOAPProxy对象收到数据，进行解析。当解析出一个服务调用时，把它交给TestService服务处理。
- TestService解析出一个方法调用，把它交给Method处理。
- Method解析出各个参数，验证参数类型、完整性等，并执行调用或返回错误。
- Method调用的返回信息(包括调用结果、返回值、out参数等)被打包成一个“集合”，交给TestService处理。
- TestService处理后，交给SOAPProxy。
- SOAPProxy把结果打包成SOAP消息，发回调用端。
- 调用端解析SOAP消息，把OUT参数值赋给调用者提供的对象，调用完成。
服务验证方式。
- 生成SOAPProxy，让它连接到远程主机。
- 生成TestService对象，调用SOAPProxy的getService验证版本。
- SOAPProxy把TestService对象的信息(名称、成员及基类型等)发送到远程主机，阻塞。
- 远程主机解析收到的信息，查找服务名，并比较查找到的服务类型与解析得到的类型。
- 比较结果发回给调用端。
- 调用端接着采用直接调用的方式，调用远程服务。
这种方式看起来多了一些操作，不过验证的好处是能够减少调用时的异常。
服务发现方式。
- 生成SOAPProxy，让它连接到远程主机。
- 查询远程开放的服务名称。(可省略)
- 查找特定服务，得到服务描述信息。
- 查找服务中的方法，得到方法描述信息。
- 压入各个参数，并执行调用。
- 调用前先判断参数是否与描述一致，然后调用SOAPProxy生成SOAP消息，发送到远程主机，阻塞。
- 远程主机解析出调用。。。后面过程与第1种方式相同，远程主机并不知道客户端使用的是哪种方式来调用。远程主机处理结束，将返回SOAP消息给调用端。
- 调用端解析出调用结果，并把各个OUT参数的值赋给method对象。
使用这种方式，调用端不需要服务的类型定义。

四、异步调用/异步分派(AMI/AMD)。

同步调用时，调用端线程需要等待调用结果，服务端线程也要等待调用结束返回，才处理下一个调用。
为了在服务调用期间让线程能做更多的事：
调用端把调用交给线程池完成，并在调用完成后采用某种机制通知线程处理结果，或者直接由线程池中的调用线程调用结果处理函数。这种方式称为AMI(异步方法调用)。
服务端主线程则把接收到的消息解析后，放入处理队列，由线程池去处理调用过程。当调用完成后，结果放入结果队列，由主线程处理成消息，发送回调用端。这种方式称为AMD(异步方法分派)。
调用端和服务端依旧是使用通讯协议来沟通，双方都不知道对方是否采用了异步方式。

AMI和AMD对于静态定义的服务是有影响的，比如下面一个服务：

struct TestService
{
Method <void(in<int>, out<int>)> method1;
}

在同步调用时，它的调用方式：

TestService test_service;
int a;
service.method1 (3, a); // 或者 service.method1 (3, &a)，打算兼容这2种方式。

异步调用时，调用方式：

void method1_result (int, int);
TestService test_service;
test_service.method1.async_call(3, method1_result); // 调用完成后，让调用线程去调用method1_result通知调用结果。
// 或者像下面
IMethod* result = test_service.method1.async_call (3);
while (!result->done()) // 还有很多好办法，这里只是为了简单。
{
sleep (1);
}
cout << result->getArg(1)->toInt();

正如上面演示的一样，异步调用的结果有2种方式去处理。
一是由线程池调用完以后，接着调用一个函数以通知结果。它不需要轮询，不过涉及到了线程问题，增加了一些复杂性。
另一种方式调用结束后，原调用线程在某个适当的“时机”去查询调用结果。这个时机可以是定时查询，也可以是被线程消息通知而去处理。

五、其它。

这一篇加上前一篇，应该是提到了全部的要点。
目前剩下的唯一一个难点，可能是在处理异步调用时，Method的定义。
正如上面演示的，一个方法在同步调用和异步调用时，就有3种调用方式：

service.method1 (3, a);
test_service.method1.async_call(3, method1_result);
IMethod* result = test_service.method1.async_call (3);

特别地，它如何根据in和个数和out的个数，产生那2个参数个数匹配的异步调用函数？
再来回顾一下method1的定义：

Method <void(in<int>, out<int>)> method1;

显然有一定的复杂性，不过我认为还是可以处理掉的。拿3个参数的偏特化版本来说明：

template <class Ret, class A, class B, class C>
class Method <Out<Ret>(A,B,C)> : public MethodBase <Out<Ret>,A,B,C>
{
};

template <class Ret=NullType, class A=NullType, class B=NullType, class C=NullType, class D=NullType, IN_COUNT=InCount< A,B,C,D>::value >
class MethodBase
{
};

通过对MethodBase类的IN＿COUNT参数定义偏特化，即可定义出这些不同的版本。

当然仅仅是知道了IN参数的个数，还没有提取出IN参数的类型，所以还不能生成函数的原型，或许需要把typelist加进来了（loki中的那个）。

这是后面要考虑的内容，今天先想到这。

qiezi 2005-09-17 19:40 发表评论

为C＋＋实现一个IDL　（零）

qiezi — Wed, 14 Sep 2005 17:27:00 GMT

一、问题。

这段时间考虑实现一个纯C＋＋的分布式服务包装库，简要描述如下：

有如下类和函数：

struct Test
{
void test1 (/*in*/ int v1, /*in*/ int* v2);
int test2 (/*in*/ int& v1, /*out*/ int* v2);
};

int test_func (/*in*/ int* v1, /*inout*/ string* v2);

想把它们作为服务发布出去，以SOAP或其它方式。发布为一个TestService，并让它携带多一些信息:

struct TestService
{
    void test1 (in<int> v1, in<int> v2);
    int test2 (in<int> v1, out<int> v2);
    int test_func (in<int> v1, inout<string> v2);
};

C＋＋有许多工具、库来做到这点，但是，都需要生成一堆代码，很是不爽。

其它语言，比如python, java, c#等，都可以通过自省机制，抛开IDL在语言内实现。

C＋＋并非不能做这个，它只是缺少足够的类型信息。比如上面的例子，如果要发布为服务，那么至少应该把它的参数、返回值搞得明确些，否则要么会造成不必要的参数传递，要么会产生错误（把OUT参数取值可不是安全的）。

比如上面出现的int, int&, int*，在作为in参数时，我们是想传递它的值，类型为int。而int*和string*作为out参数时，我们想让它传递指针或引用，当调用返回时，我们给它赋值。

C＋＋语言的类型极为丰富，却没有描述一个参数到底是in还是out。java也没有，但它可以正常序列化一个null值，在C＋＋中，这可能存在一些麻烦。

再考虑一下char*类型，假如它是in参数，那么它是要传递一个字符还是一个字符串？C＋＋语言没有对它进行描述。

所以要实现一个分布式服务包装（或代理）库，必须让发布者提供这些信息。

我们知道，要查询一个远程服务，必须查询相应主机端口，获取服务信息。最简单的服务信息包括：服务列表，每个服务中的方法列表，方法的类型（包括参数和返回值类型，in/out信息等）。

实际上，我们是要为C＋＋增加一些简单的自省能力。上面那个服务发布接口，实际上离这个要求还有很远，再来看一下：

struct TestService
{
    void test1 (in<int> v1, in<int> v2);
    int test2 (in<int> v1, out<int> v2);
    int test_func (in<int> v1, inout<string> v2);
};

可以想见，它是没有一点自省能力的，我们如何向它查询，它的名字？它的方法列表？方法的类型？它如何与Test类的成员函数以及test_func函数关联？

二、方向。

要让上面那个服务具有自省能力，要做的扩充其实并不多。考虑下面的代码：

struct TestService : public Service
{
    TestService ();
    Method <void(in<int>, in<int>)> test1;
    Method <int(in<int>, out<int>)> test2;
    Method <int(in<int>, inout<string>) test_func;
};

这几个Method可以用自己写的委托类来做。

1、假如我们在TestService的构造函数里给它分配一个“TestService”名字，并且Service类实现了查询名字的接口，那么它就知道它自己的名字了。

2、假如在TestService的构造函数里为各个Method分配名字，并且注册到TestService，那么它就能够查询方法列表。

3、方法的类型？通过模板方式，把各个参数类型收集起来，给个字符串名称就可以了。

使用宏来实现，大概可以写成这样：

通过上面这几个宏，我们能够生成TestService声明。

不过，有几个问题，罗列如下，并一一解决它：

1、如何把函数指针传给它？如何把方法名称传给它？
这个只是C＋＋语言为我们增加了一些麻烦，我们无法在定义成员的地方调用它的构造函数，不过这并不会造成多大障碍。
上面的METHOD宏如果只是生成类的声明，那么函数指针可以省略。我把它加上的原因是，它可以被我用Ctrl+C, Ctrl+V这种世界上最先进的技术原样拷贝下来，并且通过简单修改的方法实现这种世界上最先进的重用。

上面的代码经过修改，结果就成这样：

BEGIN_SERVICE (TestService)
    METHOD (void(in<int>, in<int>), test1, &Test::test1)
    METHOD (int(in<int>, out<int>), test2, &Test::test2)
    METHOD (int<in<int>, inout<string>), test_func, test_func)

    BEGIN_DEFINE (TestService)
        METHOD_DEFINE (void(in<int>, in<int>), test1, &Test::test1)
        METHOD_DEFINE(int(in<int>, out<int>), test2, &Test::test2)
        METHOD_DEFINE(int(in<int>, inout<string>), test_func, test_func)
    END_DEFINE ()

END_SERVICE ()

看上去对应得非常整齐，修改起来也比较简单。上面那部分被扩充为如下代码：

struct TestService : public Service
{
    Method <void(in<int>, in<int>)> test1;
    Method <int(in<int>, out<int>)> test2;
    Method <int(in<int>, inout<string>) test_func;
    TestService ()
    : Service ("TestService")
    {
        test1.setName ("test1");
        test1.setMethod (&Test::test1);
        this->registerMethod (&test1);
        test2.setName ("test2");
        test2.setMethod (&Test::test2);
        this->registerMethod (&test2);
        test_func.setName ("test_func");
        test_func.setMethod (test_func);
        this->registerMethod (&test3);
    }
};

基本上需要的东西都在这里了。

2、客户端的问题。

上面这种映射，直接拿到客户端会有问题，Test类和test_func函数我们并不打算交给客户端，所以使用函数指针会出现链接错误。

实际上客户端不需要这个，我们想办法把它拿掉就行了。客户端实际需要生成的代码如下：

struct TestService : public Service
{
    Method <void(in<int>, in<int>)> test1;
    Method <int(in<int>, out<int>)> test2;
    Method <int(in<int>, inout<string>) test_func;
    TestService ()
    : Service ("TestService")
    {
        test1.setName ("test1");
        this->registerMethod (&test1);
        test2.setName ("test2");
        this->registerMethod (&test2);
        test_func.setName ("test_func");
        this->registerMethod (&test3);
    }
};

还是上面提到的，C++给我们带来的麻烦。这次需要另一组宏来完成它：

BEGIN_SERVICE_D (TestService)
    METHOD_D (void(in<int>, in<int>), test1)
    METHOD_D (int(in<int>, out<int>), test2)
    METHOD_D (int(in<int>, inout<string>), test_func)

    BEGIN_DEFINE_D (TestService)
        METHOD_DEFINE_D (void(in<int>, in<int>), test1)
        METHOD_DEFINE_D(int(in<int>, out<int>), test2)
        METHOD_DEFINE_D(int(in<int>, inout<string>), test_func)
    END_DEFINE_D ()

END_SERVICE_D ()

METHOD*和METHOD_DEFINE*宏的参数都有一些多余的信息，没有去掉是因为放在一起容易看到写错的地方。（这个技巧来源于前几天看的一篇BLOG，很报歉没有记下地址）

3、使用的问题。

如何才能比较方便地使用？我考虑了下面这种方式：

template <class T>
struct IProxy;

template <class T>
struct SOAPProxy;

SOAPProxy <TestService> service;
service.connect (5000, "localhost");
int a=0;
int *n = &a;
service.test1 (3, n);
service.test1 (3, *n);
service.test2 (3, n);
service.test2 (3, *n);
service.test2 (3, NONE);
//

Method::operator ()的各个参数都将可以接受相容的类型，像上面一样，因为在TestService中我们已经定义了它要传输的值的类型。

a.NONE是什么？其实是为异步调用考虑的。假如指定某个OUT参数为NONE，则这个参数的值并不真正的OUT，而是保存在Method中。实际上Method中保存每个参数的值。

b.Method与Service如何发生关系？
从TestService的定义中我们知道，Method向Service注册自己以实现自省，但它同时也会保存Service的指向。
我们的Proxy实际上是一个继承模板，上面并没有把它指出来。它的定义是：

template <class T>
class XProxy : public T
{
//
};

所以我们的TestService其实也是模板类，它将使用XProxy中定义的序列化类。XProxy将实现Service基类中序列化虚函数以及调用虚函数。

当一个Method调用时，它会调用Service的序列化，由于被重写了，所以调用的是XProxy中的序列化方法。这个方法会把这个Method的各in/inout参数序列化，然后执行远程调用，再把调用结果反序列化给inout/out参数。

4、其它想法。

在考虑上面的定义方式时，我也考虑了其它方式，主要是返回值处理的方法，简述如下。

前面我们假设了一段将被开放为远程服务的代码：

struct Test
{
void test1 (/*in*/ int v1, /*in*/ int* v2);
int test2 (/*in*/ int& v1, /*out*/ int* v2);
};

int test_func (/*in*/ int* v1, /*inout*/ string* v2);

在前面的做法中，我们的服务描述是放在那一组宏里面，好处是不用改这段代码，坏处就是代码定义的地方和描述不在一起，协调可能会有一些不便。

我也考虑了另一种做法：

struct Test
{
idl <void(in<int>, in<int>)> test1 (int v1, int* v2);
idl <int(in<int>, out<int>)> test2 (int& v1, int* v2);
};

idl <int(in<int>, inout<string>) test_func int* v1, string* v2);

对于实现代码，只需要修改返回值为void的函数，把return;修改为return VOID;，并且为没有写此语句的分支加上此句。

VOID是一个特殊类型的静态变量，专为void返回值的函数设定。

这种做法修改了原有的代码，不过在定义服务时可以节省一些工作：

BEGIN_SERVICE (TestService)
    METHOD (test1, &Test::test1)
    METHOD (test2, &Test::test2)
    METHOD (test_func, test_func)

    BEGIN_DEFINE (TestService)
        METHOD_DEFINE (test1, &Test::test1)
        METHOD_DEFINE (test2, &Test::test2)
        METHOD_DEFINE (test_func, test_func)
    END_DEFINE ()

END_SERVICE ()

它所需要的函数类型，将由函数指针推导。

在G＋＋编译器下，可以使用typeof来获得函数指针的类型而不需要真得获得函数指针值，不过目前仅仅在G＋＋下可用。（顺便说一下，typeof已经列入c++0x）

最终我放弃了这个想法，毕竟它要修改现有的代码，某些情况下这是不可能的，而且typeof目前也不能跨编译器。

三、实现。

老实说我现在还没有一份完整的或半完整的实现，大部分想法还在头脑中，测试代码倒是写了不少，主要是用来测试上述想法能否实现，我想大部分情况都已经测试了，只需要有时间来把它实现出来。

这是我近期要做的事之一，争取月内把它做完罢。

qiezi 2005-09-15 01:27 发表评论

C++博客-qiezi的学习园地-随笔分类-asgard项目

为C＋＋实现一个IDL （五）

asgard项目遗留问题 （2005-09-27更新）

为C＋＋实现一个IDL （四）

为C＋＋实现一个IDL （三）

为C＋＋实现一个IDL （二）

为C＋＋实现一个IDL （一）

为C＋＋实现一个IDL （零）