矩阵就不用再解释了，写成泛型主要是为了几个方便：
1、方便在栈上分配空间。由于维度在编译期已知，所以可以做到在栈上分配空间。当然如果这个对象是new出来的，自然是在堆上分配，这里说的是在栈上分配这个对象时，矩阵元素所占用的空间也在栈上分配。
2、方便在编译期检查非法的矩阵运算。C++模板的强大推导能力可以在编译期推导出结果矩阵的维度。
3、泛型类在方法内联上具有优势。

这个矩阵类为了能够直接从数组赋值，使用了一个ArrayPorxy类（可参考《Imperfect C++》）。

代码如下：

template <class T, int R, int C>
class Matrix
{
    T matrix[R][C];

public:
    // Big three
    Matrix(void)
    {
        memset(matrix, 0, sizeof(matrix));
    }

    Matrix(const Matrix& rhs)
    {
        memcpy(matrix, rhs.matrix, sizeof(matrix));
    }

    Matrix& operator =(const Matrix& rhs)
    {
        memcpy(matrix, rhs.matrix, sizeof(matrix));
        return *this;
    }

public:
    Matrix(const ArrayProxy<T,R,C>& arr)
    {
        memcpy(matrix, arr.getData(), sizeof(matrix));
    }

    ~Matrix(void)
    {
    }

public:
    T get(int r, int c) const
    {
        assert(c < C && c >= 0 && r < R && r >= 0);
        return matrix[r][c];
    }

    void set(int r, int c, T v)
    {
        assert(c < C && c >= 0 && r < R && r >= 0);
        matrix[r][c] = v;
    }

    int getCols () const
    {
        return C;
    }

    int getRows () const
    {
        return R;
    }

    bool operator == (const Matrix& rhs) const
    {
        return memcmp(matrix, rhs.matrix, sizeof(matrix)) == 0;
    }

    bool operator != (const Matrix& rhs) const
    {
        return !(*this == rhs);
    }
};

template <class T, int R, int C, int C1>
Matrix<T,R,C1> operator* (const Matrix<T,R,C>& lhs, const Matrix<T,C,C1>& rhs)
{
    Matrix<T,R,C1> result;
    for (int r=0; r<R; ++r)
    {
        for (int c=0; c<C1; ++c)
        {
            int value = 0;
            for (int i=0; i<C; ++i)
            {
                value += lhs.get(r,i) * rhs.get(i,c);
            }
            result.set(r,c,value);
        }
    }
    return result;
}

template <class T, class R, class C>
Matrix<T,R,C> operator+ (const Matrix<T,R,C>& lhs, const Matrix<T,R,C>& rhs)
{
   // 
}

template <class T, class R, class C>
Matrix<T,R,C> operator* (const Matrix<T,R,C>& lhs, const Matrix<T,1,1>& rhs)
{
    // 
}

// use local object: 
X x; 
A a; 
std::string s("abc"); 
// … 
x.f(a, s); 

// use remote object : 
proxy<X> x; 
x.connect("my_host"); 
A a; 
std::string s("abc"); 
// … 
x.f(a, s); 

仅使用一个包装层就完成远程调用？从目前的C＋＋来看基本上不可能。 今天突然想到可以使用aspect c++来生成代码，因为aspect c++在生成代码时，也生成了一些简单的元信息，可以在函数里面取得函数的原型、各参数的类型等。 根据0x的描述，我编写了简单的测试代码：

#include <string>
#include <iostream>
#include <sstream>
#include <vector>
using namespace std;

class LoginService
{
public:
	virtual bool login (const string& name, const string& password, string& session) = 0;
	virtual void logout (const string& session) = 0;
};

class RemoteCall
{
public:
	bool connect (const char* host, unsigned short port)
	{
		cout << "connect success" << endl;
		return true;
	}
	bool send (const char* p, size_t len)
	{
		cout << "send: " << endl;
		cout << string(p, len) << endl;
		return true;
	}
	bool recv(char* p, size_t len)
	{
		return true;
	}
};

class RemoteLoginService : public LoginService, public RemoteCall
{
public:
	virtual bool login (const string& name, const string& password, string& session)
	{
		return false;
	}
	virtual void logout (const string& session)
	{
	}
};

int main(int argc, char *argv[])
{
	RemoteLoginService rls;
	rls.connect("localhost", 3957);
	string session;
	rls.login("lijie", "lijie", session);
	rls.logout(session);
	
	return 0;
}

aspect Remote
{
	pointcut remote_class() = "RemoteCall";
	pointcut remote_call() = derived(remote_class()) && !remote_class();

	pointcut virtual_methods() = "% ...::%(...)";

	advice within(remote_call()) && execution(virtual_methods()): before(){
		stringstream ss;
		ss << "\tcall:" << JoinPoint::signature() << endl;
		ss << "\targuments:";
		for (size_t i=0; i<JoinPoint::args(); ++i)
		{
			string arg(tjp->argtype(i));
			if (arg.find("basic_string") != arg.npos)
			{
				ss << *(string*)tjp->arg(i) << "|";
			}
		}
		string send_str = ss.str();
		tjp->target()->send (send_str.c_str(), send_str.size());
	}

	advice within(remote_call()) && execution(virtual_methods()): after(){
		vector<char> buffer(1024, '\0');
		tjp->target()->recv (&(*buffer.begin()), buffer.size());
		// 解析接收的数据，远程调用结果写入tjp->result()指向的内存
	}
};

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

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

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

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

要用到的Loki头文件：

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

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

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

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

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

, 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”，实际上应该叫“为C++实现一个Remoting”可能更好一些，说是IDL，主要是想通过宏，使用简单的类型定义达到自动生成调用代码的目的。

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

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

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

我希望就是这么简单，客户端调用有多种方式：
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:
所有类型的基类，预定义了一些基本类型，可自定义类型。

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

1. 直接调用。
   
   
   • 生成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参数值赋给调用者提供的对象，调用完成。

    

2. 服务验证方式。
   
   • 生成SOAPProxy，让它连接到远程主机。
     
   • 生成TestService对象，调用SOAPProxy的getService验证版本。
     
   • SOAPProxy把TestService对象的信息(名称、成员及基类型等)发送到远程主机，阻塞。
     
   • 远程主机解析收到的信息，查找服务名，并比较查找到的服务类型与解析得到的类型。
     
   • 比较结果发回给调用端。
     
   • 调用端接着采用直接调用的方式，调用远程服务。
   
   这种方式看起来多了一些操作，不过验证的好处是能够减少调用时的异常。

3. 服务发现方式。
   
   • 生成SOAPProxy，让它连接到远程主机。
     
   • 查询远程开放的服务名称。(可省略)
     
   • 查找特定服务，得到服务描述信息。
     
   • 查找服务中的方法，得到方法描述信息。
     
   • 压入各个参数，并执行调用。
     
   • 调用前先判断参数是否与描述一致，然后调用SOAPProxy生成SOAP消息，发送到远程主机，阻塞。
     
   • 远程主机解析出调用。。。后面过程与第1种方式相同，远程主机并不知道客户端使用的是哪种方式来调用。远程主机处理结束，将返回SOAP消息给调用端。
     
   • 调用端解析出调用结果，并把各个OUT参数的值赋给method对象。
   
   使用这种方式，调用端不需要服务的类型定义。

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

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

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

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

异步调用时，调用方式：

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

五、其它。

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

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

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

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

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



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

有如下类和函数：

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

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＋＋增加一些简单的自省能力。上面那个服务发布接口，实际上离这个要求还有很远，再来看一下：

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

二、方向。

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

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

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

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

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

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

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

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

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

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

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

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

2、客户端的问题。

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

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

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

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、其它想法。

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

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

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

我也考虑了另一种做法：

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

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

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

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

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

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

三、实现。

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

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

C++当年从应用开发的王座上跌落，不是因为它有模板，而是因为它缺少更强的动态能力。基本上C++就是一种静态语言，其所谓动态性都是就编译时而言的。一旦编译完成就成为铁板一块。这个问题在单机时代还可以将就，到了网络时代就是不可容忍的问题。因此，按照毛主席的矛盾论思想说，实际上C++在90年代中期面临的主要矛盾是落后的静态执行模型与应用程序动态化之间的矛盾。但是C++当时并没有着力解决这个矛盾（到现在连个统一的ABI都没有），反而在次要矛盾（开发效率）上下功夫，花了极大的精力去完善模板设施。再加上其他固有的问题（GC, debug, pointer, 复杂性），C++就从王座上跌下来了。

这也可以解释，为什么Windows/MFC/COM仍然是目前C++应用的单一最大场合——因为COM是微软为C++提供的一个动态运行环境。遗憾的是，COM设计得太复杂，而且犯了一些错误（读读这篇文章http://www.relisoft.com/win32/olerant.html），所以跟后来的那些什么Java、.NET相比就相形见绌了。

总之，C++仍然是目前制造单块系统最好的语言（效率高，抽象机制丰富，可移植性好），但用于构造整个应用，特别是网络应用，就很不合适了，至少是不经济。

因此，C++未来的位置只能是不断完善自己作为系统级部件语言的位置。从这个角度看：

1.    Ice：用C++开发了完整的网络中间件，解决了动态性问题，并且可以跨语言。这是我认为3年以来C++开发中最令人激动的项目。

2.    陈榕的Elastos：陈榕对于这个问题的认识是很深刻的。几年以前他给我讲得其实就是这个道理，只不过我最近才想明白。他认为在构造单个部件方面，C++由于C#、VB、Java，特别是在嵌入式平台上优势明显。而主要的缺陷是C++部件的动态性能极度匮乏，这里的关键因素又是因为C++部件中的metadata匮乏。因此陈榕给C++部件添加完整的metadata，并开发运行时来支持。陈榕的思想实际上与Ice是一致的，只不过两者一个是从CORBA出来的，一个是从COM出来的，殊途同归而已。我非常认同陈榕的发展方向，唯一的担忧是，陈榕的C++部件metadata是与.NET兼容的，而目前企业应用中的主流是Java。这个矛盾应该得到解决。如果陈榕的Elastos能够同时兼容Java的metadata和.NET的metadata，我相信他会取得成功。

3.    微软的C++/CLI，这个东西被骂得很惨，其实放在大背景下考虑，它是有意义的。实际上它的出现是同样基于我上面提到的一个观点，即做零件的话，你们谁也不如C++。所以C++是有优势的，只不过要把C++作出来的零件跟其他的零件自如拼装。C++/CLI致力于在.NET体系内部解决这个问题，不能说这个想法是不对的，我认为这个技术将会得到一定程度的应用。

4.    相比之下，像ACE/MFC/Qt这类大型的框架，虽然已经非常成熟，但是未来将局限在一个比较小的领域里，局面会比较尴尬。因为它们是用来开发整个应用程序的，而未来大家不太会用C++来开发整个应用。那么用它们来开发部件如何呢？不好，因为它们开发出来的部件不能与外界交互。不过ACE还是有一定空间的，因为它的可移植性超好，可以往嵌入时平台上挤，而且在上面还有TAO和CIAO。

5.    ATL怎样呢？那完全取决于COM的命运。只要COM在Windows中还处于核心的地位，ATL就还是很重要的技术。

6.    Boost对于C++来说，只是一个补充性质的事件，无关乎大局。

7.    我一直坚信未来会出现高低搭配的局面，像Java/C#这样的半动不静的中级语言会逐渐“沦为”JVM和CLR上的系统语言，应用开发的任务必将由更加动态的脚本语言承担。目前的Python, Ruby和Lua都有可能。如果从我的角度讲，我希望最后胜出的是Lua，因为Python思维有些混乱，Ruby虽然很纯，但是语言设计过于复杂，只有Lua是符合我的美学观——简单而又强大，这一点跟云风意见一致。