对QT_namespace_UI的理解..doc

对QT namespace UI的理解 今天许某问我一个C++语法问题。 namespace Ui { ??? class Dialog: public Ui_Dialog {}; } // namespace Ui 就是这个是什么意思，单从语法上很简单。但是他说 class Dialog : public QDialog,public Ui::Dialog { 可是奇怪的是Dialog继承了Ui::Dialog，而Ui::Dialog继承自Ui_Dialog，可是却只出现了namespace里的那一行，找不到Ui::Dialog的具体实现。于是上网查找 QT的东西没涉及过啊~ 下面转一篇，原理性的东西，后续问题再说吧 首先得弄清plmpl的原理 城门失火殃及池鱼 pImpl惯用手法的运用方式大家都很清楚，其主要作用是解开类的使用接口和实现的耦合。如果不使用pImpl惯用手法，代码会像这样： ?????? //c.hpp ??????? #includex.hpp class C ??????? { ??????? public: ??????????? void f1(); ??????? private: ??????????? X x; //与X的强耦合 ??????? }; 像上面这样的代码，C与它的实现就是强耦合的，从语义上说，x成员数据是属于C的实现部分，不应该暴露给用户。从语言的本质上来说，在用户的代码中，每一次使用”new C”和”C c1”这样的语句，都会将X的大小硬编码到编译后的二进制代码段中（如果X有虚函数，则还不止这些）——这是因为，对于”new C”这样的语句，其实相当于operator new(sizeof(C) )后面再跟上C的构造函数，而”C c1”则是在当前栈上腾出sizeof(C)大小的空间，然后调用C的构造函数。因此，每次X类作了改动，使用c.hpp的源文件都必须重新编译一次，因为X的大小可能改变了。 在一个大型的项目中，这种耦合可能会对build时间产生相当大的影响。 pImpl惯用手法可以将这种耦合消除，使用pImpl惯用手法的代码像这样： ??????? //c.hpp ??????? class X; //用前导声明取代include ??????? class C ??????? { ???????? ... ???????? private: ??????????? X* pImpl; //声明一个X*的时候，class X不用完全定义 ??????? }; 在一个既定平台上，任何指针的大小都是相同的。之所以分为X*，Y*这些各种各样的指针，主要是提供一个高层的抽象语义，即该指针到底指向的是那个类的对象，并且，也给编译器一个指示，从而能够正确的对用户进行的操作（如调用X的成员函数）决议并检查。但是，如果从运行期的角度来说，每种指针都只不过是个32位的长整型（如果在64位机器上则是64位，根据当前硬件而定）。 正由于pImpl是个指针，所以这里X的二进制信息（sizeof(C)等）不会被耦合到C的使用接口上去，也就是说，当用户”new C”或”C c1”的时候，编译器生成的代码中不会掺杂X的任何信息，并且当用户使用C的时候，使用的是C的接口，也与X无关，从而X被这个指针彻底的与用户隔绝开来。只有C知道并能够操作pImpl成员指向的X对象。 防火墙 “修改X的定义会导致所有使用C的源文件重新编译”这种事就好比“城门失火，殃及池鱼”，其原因是“护城河”离“城门”太近了（耦合）。 pImpl惯用手法又被成为“编译期防火墙”，什么是“防火墙”，指针？不是。C++的编译模式为“分离式编译”，即不同的源文件是分开编译的。也就是说，不同的源文件之间有一道天然的防火墙，一个源文件“失火”并不会影响到另一个源文件。 但是，这里我们考虑的是头文件，如果头文件“失火”又当如何呢？头文件是不能直接编译的，它包含于源文件中，并作为源文件的一部分被一起编译。 这也就是说，如果源文件S.cpp使用了C.hpp，那么class C的（接口部分的）变动将无可避免的导致S.CPP的重新编译。但是作为class C的实现部分的class X却完全不应该导致S.cpp的重新编译。 因此，我们需要把class X隔绝在C.hpp之外。这样，每个使用class C的源文件都与class X隔离开来（与class X不在同一个编译单元）。但是，既然class C使用了class X的对象来作为它的实现部分，就无可避免的要“依赖”于class X。只不过，这个“依赖”应该被描述为：“class C的实现部分依赖于class X”，而不应该是“class C的用户使用接口部分依赖于class X”。 如果我们直接将X的对象写在