第四部分 将可重用的部分做成静态库

4.1 导入示例项目
　　点此处可以下载本文中用到的两个C++项目（Eclipse+CDT项目，环境按第一部分的说明配置），下载后解压。
　　然后在Eclipse中使用File->Import->Genaral::Existing Project into Workspace向导即可把下载的项目导入到开发环境中。便会看到如下图的项目：

　　如果Build成功，Run起来以后，可以看到如下的运行结果：

　　这个例子实际上和上一部分中的例子效果是一样的。不同的是，本例中使用了静态库的方式来完成，这样更可以看出程序在扩展意义上的实践。那么如何建立一个静态库（static library）？又如何在另一个项目中引用这个库？下面两个小节就是分别回答这两个问题的。

4.2 静态库项目的建立

　　静态库项目的建立在CDT中是非常方便的。用新建向导中的 New -> C++ Project -> Static Library -> Empty Project即可建立成功。然后可以在该项目中进行代码的编写。如果编译成功，可以看到项目结构如下所示：

　　注意那个Archives里面生成的一个***.a文件，这就是代码编译生成的静态库。

4.3 静态库项目的调用

　　下面就来新建一个普通C++项目，来引用并调用上一小节库中的代码。新建的过程也很简单，就用新建向导中的New -> C++ Project -> Executable -> Empty Project即可。

　　建完以后，来添加对4.2中所建立的静态库的引用。

　　1：头文件

　　因为我们要对静态库中的类进行调用并扩展，所以一般需要引用静态库项目中的一个对外公布的头文件（如本例中的InshionLib.h）。

　　具体做法如上图所示，在/C/C++ Build -> Settings 中的GCC C++ Compiler的Directories中把需要引用的静态库的Include paths添加进来。这样做的目的是为了让Inshion_Exa002_Caller项目（下简称Caller项目）中的#include "InshionLib.h"能正确通过。

　　2：引用库和参数配置
　　当然，只引入头文件是远远不够的。以Caller项目为例，如果只是添加了头文件目录，然后就编译那几个源码的话，一般会出现如下的错误：

　　undefined reference to `WinMain@16'
　　undefined reference to `TextOutA@20'
　　undefined reference to `SetBkColor@8'
　　等等等等……

　　所以我们还需要把Lib项目生成的库引进来，同时设置WindowsAPI调用需要添加的配置参数。具体作法如下图所示：

　　具体地说就是在MinGW C++ Linker的Miscellaneous中的Other objects下，添加前文提到的静态库编译生成的***.a库文件。

　　然后设置-lmingw32和-mwindows参数，分别参照以下两图进行：

 

　　顺便提一下，其实-mwindows这个参数我们已经不陌生了，第三部分中就用过它，这里的使用与之是完全一样的。具体可参见本系列文章的第三部分。

　　这样设置完成以后，就可以再Build该Caller项目了，应该就可以通过:D。

4.3 其它可能遇到的问题

　　在对源代码或者编译参数进行修改了以后，最好使用Eclipse菜单的Project -> Clean 功能对项目进行一下清理，以保证再次生成的时候我们的所有修改都是生效有。
　　有时候，在对两个项目同时进行Clean并Build之后，会出现下面这样的提示：
　　..\: No such file: No such file or directory
　　其实他的意思是说那个***.a文件没有找到。这时候需要检查一下上文（4.2小节）提到的Archives里是否有我们想要的.a文件，如果我们的引用设置和Lib项目的.a文件都是正常的，说明这是Eclipse资源同步的问题，这时候并没有关系，再对Caller项目单独一下Build就行。

　　这个问题不仅现在会遇到，后面我们还会看到，在使用资源文件（.res）生成.o文件的时候，常常也会发生。通常是.o文件明明已经生成了，但Eclipse的项目里却看不到，这时候只需要用F5刷新（或者在项目上点右键选刷新）一下该项目就能看到我们需要的文件，再编译连接就能正常。

 

附：本文中的源代码项目下载（Inshion_Exa002.rar）

 

 

 

第三部分 一个Demo程序及相关说明

3.1 在Eclipse中导入并运行一个C++项目
　　点此处可以下载本文中用到的C++项目（Eclipse+CDT项目，环境按第一部分的说明配置），下载后解压。
　　然后在Eclipse中使用File->Import->Genaral::Existing Project into Workspace向导即可把下载的项目导入到开发环境中。便会看到如下图的项目：

　　如果Build成功，Run起来以后，可以看到如下的运行结果：

　　同时控制台给出以下输出：

　　Main Program Started!
　　Application::SetWinMainArgs(...)
　　MyApp::InitInstance() -- start
　　Window::Create(...) <--> start
　　Application::RegisterWndClass(...) <--> start
　　Application::RegisterWndClass(...) <--> end
　　Window::Create(...) <--> end
　　MyApp::InitInstance() -- end
　　Application::Run()

　　但是需要注意的是，如果是直接新建一个项目，再编写如此的程序代码，调用WindowsAPI，一般情况下直接编是编不通的，会提示某种错误
　　比如：undefined reference to `TextOutA@20'
　　或者是：undefined reference to `SetBkColor@8'等
　　因此要对项目加上一个参数设置。具体的设置项目如下：
　 　在项目上点右键，选择“属性”，就会弹出Eclipse的项目设置对话框，在按图所示的地方添加-mwindows参数即可（C/C++Build -> Settings ->MinGW C++ Linker -> Expert settings:）。注意，这些选项页中有很多相似的页面，看清图示的设置框究竟是哪一个（MinGW C++ Linker），不要加错地方了（=0=|||）。

　　顺便提一句，随着我们对项目的扩展，可能有越来越多的项目需求，比如引用静态库、引用DLL、使用rc资源等，这些要求都涉及到对项目属性中某些参数的修改。本部分中只涉及-mwindows参数，其它的参数会在后续的部分中分别介绍。
　　OK，如果项目运行成功，我们就来分析一下这个项目的结构，看是否和第一部分描述的是同样的组织方式。

3.2 源代码说明
　　回顾一下第一部分中提到的Windows应用程序的运行示意图：

　 　对照本文中给出的项目，可以看出Main.cpp中就是程序的入口WinMain()函数；Application类（包括.h与.cpp两部分）就是 图示的Application；Window类（包括.h与.cpp两部分）就是图示的Window部分；而application变量（在 Application.cpp中声明）就是图中左上角那全局变量。
　　也就是说，本项目中的Application、Window两个类再加上一个WinMain()函数就完成了一个Windows程序需要的基本框架。这三个类写定以后，就不需要再作改变（架构意义上而言…）！而我们的后续开发扩展功能的工作，就只需要进行一些简单的添加就能完成（下面马上讲到的MyWin和MyApp两个类的作用），下面就是扩展部分的说明。
　　还是先看看第一部分中提到的扩展程序示意图：

　　MyApp和MyWin两个类，就是我们自己扩展出来的。实现上图中My Program的功能。可以看到，我们的子类MyWin的OnPaint()方法在运行过程中已经取代了基类Window的OnPaint()方法，替我们输出了一个文本。
　 　总结一下，整个这个例子想要说明的一个问题就是：如果我们的底层结构（Application、Window两个类）写得足够好了，我们以后的开发只需 要做MyWin和MyApp两个类，在其中添加我们的功能即可，这种添加只需要很少的代码量，如本例中的这两个扩展类其实只有如下的内容，并且结构很清晰。
（MyApp和MyWin类）

　　另外再提一下，我们可以试着把MyApp.h中的成员变量定义
　　MyWin MainWin;
　　改回基类
　　Window MainWin;
　　此时的运行结果就是弹出一个基类的Window，而与MyWin无关（可以把MyWin相关的代码删掉，依然不影响运行）。这一方面说明，如果我们的 很多需求是大量重复的，就完全可以在基类里做好，扩展时都不用写MyWin这样的窗口类；另一方面说明，即使我们要自己做扩展，也是非常方便地添加一个窗 口类就可以。

　　下一部分将介绍如何把基类们封装成静态库项目，以便更方便地复用。

附：本文中的源代码项目下载（MyMain_Inshion_Exa001.rar）

第二部分 Windows编程、面向对象程序设计

2.1 Windows编程回顾
　　提到Windows编程，简单地说，就是调用WIndows API做Windows应用程序。比如画个窗口，写个菜单，放个按钮，响应响应鼠标之类的。基本上所有的相关入门教程，都会用以下这样一个小例子，来演示一个最简单的Windows应用：
//------------Start---------------
#include ...

//回调函数
LRESULT   WndProc(){
　　//switch msg
　　...
　　WM_PAINT:
　　OnPaint();
　　...
}

void OnPaint(){ //draw }

//入口
int WinMain(){
　　//1：注册窗口类，并将该窗口的回调函数调为WndProc
　　//2：建立并显示窗口
　　//3：进入消息循环
}

//------------End---------------

　 　从上面程序可以看出，正常的Windows程序编写，都会有上述的1、2、3步。这样一来，运行时一个Win窗体就会诞生，并且源源不断地接收系统和用 户发给它的各种消息，比如单击、移动、关闭等。然后在此基础上，我们就可以编写自己的功能，比如每当单击窗口的某一处就显示一个图片、每当用户点关闭按 钮，就弹出一个提示框，等等诸如此类的操作。这些功能都需要在WndProc的switch语句中添加。由此就产生了一个问题。
　　“我是不是需要经常改动WndProc或者它所调用的函数(如OnPaint)的内容？”
　 　OK，一般说来，是这样的。所以这会给开发造成很多麻烦，比如需要经常修改同一段代码，又比如每建立一个应用程序，都要重复写以上的那个结构…等等等 等。于是我们就郁闷了，开始考虑怎么才能来点儿一劳永逸的办法，使得上述那样3步可以固化下来，以后再要开发，只需要写功能，不需要对已经写好的东西再复 制或者修改了。幸运的是，面向对象的开发方法给了我们很好的解决方案。

2.2图解程序结构
　　结过分析，我们发现Window应用程序，一般都有着如下的结构。
　　即入口WinMain通过一个全局的Application * application来调用Application的InitInstance()方法，而Application::InitInstance()中 又调用Window::Create()方法。这样一来，Window被创建，而系统、用户消息，如WM_PAINT之类的就可以传由Window的相应 处理函数来处理。这样一来，程序底层就完成了，简单地说，这是一个没有任何功能的，但是可以接受各种消息的Windows应用。

　　当我们想添加自己的功能时，只需要按照下图所示，分别继承Application和Window类。并在WinMain执行之前让全局的application指向MyApp的实例，这样一来，新程序中所有的消息就会转到我们自己的MyWin类中来处理，我们就可以随心所欲地添加自己的功能。

　　到此，可能有人会有疑问：“在WinMain执行之前让全局的application指向MyApp的实例”？WinMain不是程序入口吗，怎么能在它执行之前还能做别的操作？
　　这个问题甚至不需要回答，如果有此疑问的，请运行下面这样一段小程序，看看输出就明白了，为什么在WinMain之前还可以做很多很多操作：

2.3用对象封装WindowsAPI
　　面向对象编程的重点在于需要进行抽象。
　　来看看上述的WIndows程序的建立过程，都是那样3步，于是我们把它总结出来，写成这样几个部分。
//----------------------------
class App{
　　App(){ app = this; }
　　init();//调用Window的create方法
　　run();//3：进入消息循环
　　Window * MainWin;
}
App * app;
//----------------------------

//----------------------------
class Window{
　　create();//1：注册窗口类，并将该窗口的回调函数调为WndProc 2：建立并显示窗口
　　virtual WndProc();//将消息映射到具体的处理函数 如WM_PAINT映射到OnPaint()
　　virtual OnPaint();
　　...
}　　　　
//----------------------------

//----------------------------
//入口
int WinMain(){
　　app->init();
　　app->run()
}
//----------------------------
　　OK，这个结构是什么意思？简单地说，就是把应用程度做成一个类，窗口做成一个类。程序入口调用程序的init()方法，该方法会调用窗口的create()方法，最后调用程序的run()方法完成程序的加载。
　　这样做的好处是什么？
　　回答是：可以完全不改动这些代码，只需要添加新的代码，并且新的代码只需要关注自己新的功能，不需要知道消息从哪来，往哪去就可以开发出我们自己的应用程序！
　　为什么可以这样？
　　举例说明一下。（注意那个App的指针app，以及App构造函数中的app = this;，再看看那几个virtual函数。）
　　比如我们要建立自己的应用，可以写一个如下的类：

//----------------------------
MyApp theApp;
　　MyApp : public App{
　　Window win;
　　init(){ win.create(); MainWin = &win; }
}
//----------------------------

//----------------------------
MyWin: public Window{
　　OnPaint();
　　OnClose();
　　...
}
//----------------------------

　　只要这样，我们就可以在MyWin的OnXXXX()方法里实现我们自己的功能，而前面编好的那几个类，可以不做任何改动，就可以支撑起整个程序的过程调用，我们甚至不需要上面那些源代码了，只需要将编译好的库和头文件引进来，就可以在其基础上进行扩展。
　 　整个调用过程是，App的实例化由MyApp theApp;完成，由于App的构造函数中有app =  this;，所以此时app指向的是MyApp的实例。当程序接收到消息时，会通过WndProc找到对应的处理函数（比如WM_PAINT对应到 OnPaint()方法），此时会调用MainWin->OnPaint()。而由于MainWin的实例是MyApp::init()中生成的， 是MyWin的实例，而MyWin中将virtual的OnPaint()进行了重载，所以该调用会调到MyWin::OnPaint()方法。
　　总结起来，这实际上完成了一个将WindowsAPI的过程封装成C++类的过程，用类和对象架起了用户调用与WindowsAPI之间的一座桥梁。这里可以提一句关于MFC的话题，MFC所做的事情，就是这样一个将WindowsAPI的过程封装成C++类的过程，当然，它的结构更为严谨而复杂，考虑的事情也更多，远不是一两句话能说完，不过其思想与程序封装完的入口，与上述过程如出一辙。
　　至此，我们就清楚了如何用面向对象思想解决Windows程序的问题。在下一部分中，我将完整地给出一个C++程序（Eclipse+CDT），并且总结一些Eclipse中编译运行之可能遇到的问题，用以完成这部分所描述的内容。