Qt之路1--hello world

Qt 是一个著名的 C++ 应用程序框架。你并不能说它只是一个 GUI 库，因为 Qt 十分庞大，并不仅仅是 GUI 组件。使用 Qt，在一定程度上你获得的是一个“一站式”的解决方案：不再需要研究 STL，不再需要 C++ 的，不再需要到处去找解析 XML、连接数据库、访问网络的各种第三方库，因为 Qt 自己内置了这些技术。

Qt 是一个跨平台的框架。跨平台 GUI 通常有三种实现策略：
API 映射：API 映射是说，界面库使用同一套 API，将其映射到不同的底层平台上面。大体相当于将不同平台的 API 提取公共部分。比如说，将 Windows 平台上的按钮控件和 Mac OS 上的按钮组件都取名为 Button。当你使用 Button 时，如果在 Windows 平台上，则编译成按钮控件；如果在 Mac OS 上，则编译成按钮组件。这么做的好处是，所有组件都是原始平台自有的，外观和原生平台一致；缺点是，编写库代码的时候需要大量工作用于适配不同平台，并且，只能提取相同部分的 API。比如 Mac OS 的文本框自带拼写检测，但是 Windows 上面没有，则不能提供该功能。这种策略的典型代表是 wxWidgets。这也是一个标准的 C++ 库，和 Qt 一样庞大。它的语法看上去和 MFC 类似，有大量的宏。据说，一个 MFC 程序员可以很容易的转换到 wxWidgets 上面来。
API 模拟：前面提到，API 映射会“缺失”不同平台的特定功能，而 API 模拟则是解决这一问题。不同平台的有差异 API，将使用工具库自己的代码用于模拟出来。按照前面的例子，Mac OS 上的文本框有拼写检测，但是 Windows 的没有。那么，工具库自己提供一个拼写检测算法，让 Windows 的文本框也有相同的功能。API 模拟的典型代表是 wine —— 一个 Linux 上面的 Windows 模拟器。它将大部分 Win32 API 在 Linux 上面模拟了出来，让 Linux 可以通过 wine 运行 Windows 程序。由此可以看出，API 模拟最大优点是，应用程序无需重新编译，即可运行到特定平台上。另外一个例子是微软提供的 DirectX，这个开发库将屏蔽掉不同显卡硬件所提供的具体功能。使用这个库，你无需担心硬件之间的差异，如果有的显卡没有提供该种功能，SDK 会使用软件的方式加以实现。
GUI 模拟：任何平台都提供了图形绘制函数，例如画点、画线、画面等。有些工具库利用这些基本函数，在不同绘制出自己的组件，这就是 GUI 模拟。GUI 模拟的工作量无疑是很大的，因为需要使用最基本的绘图函数将所有组件画出来；并且这种绘制很难保证和原生组件一模一样。但是，这一代价带来的优势是，可以很方便的修改组件的外观——只要修改组件绘制函数即可。很多跨平台的 GUI 库都是使用的这种策略，例如 gtk+（这是一个 C 语言的图形界面库。使用 C 语言很优雅地实现了面向对象程序设计。不过，这也同样带来了一个问题——使用大量的类型转换的宏来模拟多态，并且它的函数名一般都比较长，使用下划线分割单词，看上去和 Linux 如出一辙。gtk+ 并不是模拟的原生界面，而有它自己的风格，所以有时候就会和操作系统的界面格格不入。），Swing 以及我们的 Qt。

Qt 和 wxWidgets 一样，也是一个标准的 C++ 库。但是它的语法类似于 Java 的 Swing，十分清晰，而且使用信号槽（signal/slot）机制，让程序看起来很明白——这也是很多人优先选择 Qt 的一个很重要的原因。不过，所谓“成也萧何，败也萧何”。这种机制虽然很清楚，但是它所带来的后果是你需要使用 Qt 的 moc 对程序进行预处理，才能够再使用标准的 make 或者 nmake 进行正常的编译，并且信号槽的调用要比普通的函数调用慢大约一个数量级（Qt 4 文档中说明该数据，但 Qt 5 尚未有官方说明）。Qt 的界面也不是原生风格的，尽管 Qt 使用 style 机制十分巧妙地模拟了原生界面。另外值得一提的是，Qt 不仅仅能够运行在桌面环境中，还可以运行在嵌入式平台以及手机平台。

伴随着 Qt，一直有两种授权协议：商业授权以及开源授权。在 Qt 的早期版本，商业授权包含一些开源授权不提供的组件，但是在近期版本则不存在这个问题。以往人们对 Qt 的开源授权多有诟病。早期版本的 Qt 使用与 GPL 不兼容的协议授权，这直接导致了 KDE 与 GNOME 的战争（由于 Linux 使用 GPL 协议发布，GPL 协议具有传染性，作为 Linux 桌面环境的 KDE 却是基于与 GPL 不兼容的 Qt 开发，这就不遵守 GPL 协议）。不过，现在 Qt 的开源版本使用的是 GPLv3 以及 LGPL 协议。这意味着，你可以将 Qt 作为一个库连接到一个闭源软件里面。可以说，Qt 协议的争议已经不存在了。

想要学习 Qt 开发，首先要搭建 Qt 开发环境。好在现在搭建 Qt 开发环境还是比较简单的。我们可以到 Qt 官方网站找到最新版本的 Qt。在 Downloads 页面，可以看到有几个版本的 Qt：Qt SDK、Qt Library、Qt Creator 等等。它们分别是：

Qt SDK：包含了 Qt 库以及 Qt 的开发工具（IDE、i18n 等工具），是一套完整的开发环境。当然，这个的体积也是最大的（Windows 平台大约 1.7G，其它平台大约 780M）。如果仅仅为开发 Qt，建议选择这一项下载安装。安装方法很简单，同普通程序没有什么区别。所需注意的是，安装过程中可能能够提供选择是否安装源代码，是否安装 mingw 编译器（Windows），这个就按照需要进行选择即可。另外值得说明的是，Qt SDK 通常比单独的 Qt 库版本要旧一些。比如现在 Qt 正式版是 4.8.2，但是 Qt SDK 的最新版 1.2.1 中包含的 Qt 是 4.8.1。
Qt Library：仅包含 Qt 库。如果您已经安装了 Qt 开发环境，为了升级一下 SDK 中提供的 Qt 库版本，就可以安装这一个。安装过之后，应该需要在 IDE 中配置安装路径，以便找到最新版本的 Qt（如果不是覆盖安装的话）。
Qt Creator：基于 Qt 构建的一个轻量级 IDE，现在最新版是 2.5.2，还是比较好用的，建议使用 Qt Creator 进行开发。当然，如果你已经习惯了 VS2010 这样的工具，可以在页面最下方找到相应的 Addin。很多朋友希望阅读 Qt 代码以提高自己的开发水平。当然，Qt 的经典代码是 KDE，不过这个项目不大适合初学者阅读。此时，我们就可以选择阅读 Qt Creator 的代码，它的代码还是比较清晰的。

在 Qt Creator 中，我们可以在菜单栏的工具-选项-构建和运行的“Qt 版本”和“工具链”这两个选项卡中配置 Qt Creator 所使用的 Qt 版本和编译器。这或许是最重要的步骤，包括添加新的 Qt 版本以及以后的切换编译器或者 Qt 升级等。

下面尝试开发第一个 Qt 项目：HelloWorld。在 Qt Creator 中新建一个工程：

点击这个“新建文件或工程”，在左侧选择项目-Applications，中间选择 Qt Gui 应用，然后点击“选择…”：

在弹出的对话框中填写名称、创建路径等信息：

点击“下一步”，选择该工程的编译器。这里我们只选择 mingw 调试即可（在以后的项目中，根据自己的需要选择。）Shadow Build 的含义是“影子构建”，即将构建生成的文件不放在源代码文件夹下。这样可以最大地保持源代码文件夹的整洁。

点击“下一步”，可以选择生成的主窗口文件。不过在我们的简单示例中是不需要这么复杂的窗口的，因此我们尽可能简单地选择，将“创建界面”的选择去除：

终于到了最后一步。这里是在询问我们是否添加版本控制。对于我们的小项目当然是不需要的，所以选择“无”，然后点击“完成”即可：

可以看到，Qt Creator 帮助我们在 HelloWorld 项目文件夹下生成了四个文件：main.cpp，mainwindow.cpp，mainwindow.h 和 HelloWorld.pro。pro 文件就是 Qt 工程文件（project file），由 qmake 处理，生成 make 程序所需要的 makefile；main.cpp 里面就是一个main函数，作为应用程序的入口函数；其他两个文件就是先前我们曾经指定的文件名的文件。

我们将 main.cpp 修改如下：

#include <QApplication>
#include <QLabel>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QLabel label("Hello, world");
    label.show();

    return app.exec();
}

点击 Qt Creater 左侧下面的绿色三角按钮即可运行（这里一共有三个按钮，从上到下分别是“运行”、“调试”和“构建”）。如果没有错误的话，就会看到运行结果：

这个程序有这么几行。我们解释一下。

前两行是 C++ 的 include 语句，这里我们引入的是QApplication以及QLabel这两个类。main()函数中第一句是创建一个QApplication类的实例。对于 Qt 程序来说，main()函数一般以创建 application 对象（GUI 程序是QApplication，非 GUI 程序是QCoreApplication。QApplication实际上是QCoreApplication的子类。）开始，后面才是实际业务的代码。这个对象用于管理 Qt 程序的生命周期，开启事件循环，这一切都是必不可少的。在我们创建了QApplication对象之后，直接创建一个QLabel对象，构造函数赋值“Hello, world”，当然就是能够在QLabel上面显示这行文本。最后调用QLabel的show()函数将其显示出来。main()函数最后，调用app.exec()，开启事件循环。我们现在可以简单地将事件循环理解成一段无限循环。正因为如此，我们在栈上构建了QLabel对象，却能够一直显示在那里（试想，如果不是无限循环，main()函数立刻会退出，QLabel对象当然也就直接析构了）

#include <QApplication>
#include <QLabel>

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);

    QLabel *label = new QLabel("Hello, world");
    label->show();

    return app.exec();
}

首先，按照标准 C++ 来看这段程序。这里存在着内存泄露。当exec()退出时（也就是事件循环结束的时候。窗口关闭，事件循环就会结束），label 是没办法 delete 的。这就造成了内存泄露。当然，由于程序结束，操作系统会负责回收内存，所以这个问题不会很严重。即便你这样修改了代码再运行，也不会有任何错误。

早期版本的 Qt 可能会有问题，不过在新版本的 Qt 基本不存在问题。在新版本的 Qt 中，app.exec()的实现机制确定，当最后一个可视组件关闭之后，主事件循环（也就是app.exec()）才会退出，main()函数结束（此时会销毁app）。这意味着，所有可视元素已经都关闭了，也就不存在后文提到的，QPaintDevice没有QApplication实例这种情况。另外，如果你是显式关闭了QApplication实例，例如调用了qApp->quit()之类的函数，QApplication的最后一个动作将会是关闭所有窗口。所以，即便在这种情况下，也不会出现类这种问题。由于是在main()函数中，当main()函数结束时，操作系统会回收进程所占用的资源，相当于没有内存泄露。不过，这里有一个潜在的问题：操作系统只会粗暴地释放掉所占内存，并不会调用对象的析构函数（这与调用delete运算符是不同的），所以，很有可能有些资源占用不会被“正确”释放。