C++的进阶之路该如何开启？升天还是入土！

在大多数开发或者准开发人员的认识中，C/C++ 是一门非常难的编程语言，很多人知道它的强大，但因为认为“难”造成的恐惧让很多人放

我从学生时代开始接触 C/C++，工作以后先后担任过 C++ 客户端和服务器的开发经理并带队开发，至今已经有十多年了。虽然时至今日哪种编程语言对我来说已经不再重要， C/C++ 仍然是笔者最喜欢的编程语言。在我看来，C/C++ 一旦学成，其妙无穷，就像武侠小说中的“九阳神功”一样，有了这个基础，您可以快速学习任何语言和编程技术。

目前 C/C++ 的应用领域

需要注意的是本文不细分C 与C++的区别，通常情况下，C++ 可以看成是 C 的一个超集，在古典时期，可以认为 C++ 就是C with classes。虽然如今的C++从功能层面上来看，离 C 越来越远了；但是从语法层面来上来看，大多数 C++ 语法还是与 C 基本一致的，所谓 C++ 的面向对象特性，如果细究 C++ 类方法的具体语法还是 C 的过程式语法。当然，面向对象是一种思想，语言本身对其支持的程度固然重要，能否熟练地使用则是更要看开发者的水平了。

C 语言目前主要用于像操作系统这样一类偏底层的的应用开发，包括像 Windows/linux等这样的大型商业操作系统，和嵌入式操作系统、嵌入式设备上的应用。还有一些开源的软件，也会选择C开发，这些系统主要优先考虑程序执行效率和生成的可执行文件的体积（C 代码生成的可执行文件体积相对更小），当然还有一些是历史技术选型问题，这类软件以redis、libevent、nginx，目前像国内的电信服务商所使用的电话呼叫系统一般也是基于一款叫freeswitch的开源 C 程序做的二次开发。

C++ 面向对象的语法与C相比较起来，在将高级语言翻译成机器二进制码的时候C++ 编译器在背后偷偷地做了大量工作，生成了大量的额外的机器码，而这种机器码相对于C来说是不是必须的。例如，对于一个C++类的实例方法，编译器在生成这个方法的机器码时，会将函数的第一个参数设置成对象的this指针地址，以此来实现对象与函数的绑定。正因为如此，许多开发者会优化和调整编译器生成的汇编代码。

我们再来说说 C++，C++ 的应用领域目前有三大类，第一类就是我们目前见到的各种桌面应用软件，尤其 Windows 上桌面软件，如QQ、安全类杀毒类软件、各种浏览器等等；另外就是一些基础软件和高级语言的运行时环境，如大型数据库软件、Java虚拟机、C#的 CLR 运行时、python编译器和运行时环境等等；第三类就是一些业务型应用软件的后台，如游戏的服务器后台，例如魔兽世界的服务器和一些企业内部的应用系统，笔者从在某交易所从事后台开发，其交易系统和行情系统就是基于 C++ 开发的。

C++ 与操作系统平台

从上面的介绍可以看出，与Java、python等语言相比，C/C++语言是运行在离操作系统最近的一种高级语言，因此其执行效率也比较高，但是有得必有失，也因为如此，所以C/C++这门语言存在如下特点：

C/C++ 整套的语法不具备“功能完备性”，单纯地使用这门语言本身提供的功能您无法创建任何有意义的程序，您必须借助操作系统的 API 接口函数来达到相应的功能。当然，随着 C++ 语言标准和版本的不断更新升级，这种现状正在改变；而像 Java、python 这类语言，其自带的 sdk 提供了各种操作系统的功能。举个例子，C/C++语言本身是不具备网络通信功能的，必须使用操作系统提供的网络通信函数（如socket系列函数）；而对于Java来说，其 jdk 自带的 java.net和 java.io等包则提供了完整的网络通信功能。我在读书的时候常常听人说，QQ、360安全卫士这类软件是用 C/C++ 开发的，但是当我学完整本 C/C++ 教材以后，仍然写不出来一个像样的窗口程序。许多过来人应该都有类似的困惑吧？其原因是一般 C/C++ 的教材不会教你如何使用操作系统 API 函数的内容。

正因为 C/C++ 语言需要直接使用了操作系统的接口功能，这就造成了 C/C++ 语言繁、难的地方，如操作内存方面不当容易引起程序宕机，不同的操作系统的 API 接口使用习惯和风格也不一样，接口函数种类繁多，开发者如果想开发跨平台的程序，必须要学习多个平台的接口函数和对应的系统原理。

在应用层开发，直接使用操作系统的接口的函数，往往执行效率高，控制力度大，您的开发能力仅仅限制于操作系统本身，Java 这类语言，很多功能即使操作系统提供的，如果 Java 虚拟机不提供，开发人员也无法使用。正如著名的编程大师Charles Petzold说的：显而易见，究竟用哪种方式编写应用程序最好，其实并无一定之规。应用程序本身的特性应该是决定采用何种编程工具的最主要因素，但是无论将来你采用什么样的编程工具，通过了解操作系统 API 从而深入理解操作系统的工作原理，这本身就有很重要的意义。操作系统是一个非常复杂的系统，在 API 之上加一层编程语言并不能消除其复杂性，最多不过是把复杂性隐藏起来而已。说不定什么时候，这种复杂的那一面迟早会蹦出来拖你的后腿，懂得系统 API 能让你到时候更快地挣脱困境。在基本操作系统 API之上的任何软件层或多或少都会限制你使用操作系统的全部功能。比如，你或许发现采用 Visual Basic 来编写你的应用程序非常理想，但是就有那么一两项非常基本的功能 Visual Basic 无法支持。往往这个时候你得非要调用基本 API 。作为直接使用操作系统 API 的程序员，我们的活动空间完全由 API 来规范，再没有什么其他方式比直接调用 API 更有效、更灵活多样了

总结起来，C/C++语言的开发核心是建立在直接调用操作系统 API 的基础上的，优点是执行效率高、发挥空间大；缺点是，需要经过系统深入的学习，学习周期长，编写代码较复杂、容易出错。

linux C++ 与Windows C++ 领域之争

我之所以把这一个标题单独列出来，是想纠正现在很多 C/C++ 新人和初学者的一些的不当认识，一般有以下几种观点：

linux C++开发就是后台开发，而 Windows C++ 开发就是客户端开发；

后端开发比客户端开发（前端）高级，因此后端开发行业薪资水平比客户端开发薪资要高；

我只学 linux，不学Windows。

我相信对于80和90这一代的开发者来说，当初接触计算机并进入软件行业，都是从接触 Windows 开始的。时至今日，大数据、人工智能等各种新技术方兴未艾，移动互联网如火如荼。但是无论是 linux 还是 Windows，尤其是Windows，还是我们大多数人工作、学习、娱乐使用最多的操作系统，我们每天都会使用上运行在其上的各种软件。我们使用这些软件像喝水、呼吸空气一样自然，所以很多人就忽视了这类软件的“基础作用”。对于 Windows 上的软件开发由于其发展了很多年了，这些领域也比较成熟，一般不再招初中级开发，而是需要水平较高、经验较丰富的高级开发者，这让很多人造成了“Windows C++”开发市场需求已经很小了的错觉。试问，PC QQ部门这些年对外招了多少人？

另外，linux C++ 和 Windows C++ 一样，没有孰高孰低之分，只是两种不同的操作系统而已，不要觉得在linux 下敲命令就比在 Windows 的图形化界面点击鼠标高级。图形化界面之于命令行，是人们对更高级、更方便的工具的追求的必然结果。linux C++ 也不一定就是后台开发，Windows C++ 也不一定就是客户端开发；所谓的服务器与客户端是个相对的概念，即谁给谁提供服务，提供服务的我们认为是服务端（后台），被服务的我们认为是客户端（前台）。而 Windows 作为后台服务的应用也比比皆是，如笔者之前所在的某交易所的服务器后台都是Windows下的C++程序；另外如一些游戏类的服务器端，也不少是Windows的。

借用《UNIX编程艺术》这本书的观点，Windows 和linux 的哲学理念不一样，Windows是假设你不会操作，它教你如何操作，而 linux 是假设你会操作然后进行操作；根据这个理念，Windows 一般普通人用的多，而linux 程序员用的多。从编程的角度来说，Windows的代码风格是使用所谓的匈牙利命名法，而linux使用的短小精悍的连字符风格，例如同一个表示屏幕尺寸的整型变量，Windows 上可能被命名为 iScreen 或 cxScreen ，而 linux 可能是 screen；再例如 Windows 上创建线程的函数叫 CreateThread，linux 下叫pthread_create。有时候，我觉得 Windows 的匈牙利命名法反而更容易理解代码。

这里既然提到前端（客户端）开发和后端开发，这里不得不提一下，这二者没有优劣之分。其侧重点和开发思维是不一样的，前端（客户端）开发一般有较多的界面逻辑，它们是直接与用户打交道的，因而一款客户端软件的好坏很大程度上取决于其界面的易用性和流畅性，开发者只要把这一端的“一亩三分地”给管理好即可；而后端服务，对于普通用户是透明的，开发者的程序必须尽量体现“服务”这个字眼，即更有效地为更多的客户端服务，这就要求兼顾请求响应的正确性、及时性和流畅性，由于服务软件也是运行在某台物理机器上的程序，鉴于CPU、内存、网络带宽资源有限，而服务程序一般是长周期运行的，因此必须合理的分配和使用资源（如尽量回收不再使用的各种资源），开发者应从全局考虑，不能在某个“客户端”这一棵树上“吊死”。

从个人的职业发展来看，建议从事客户端开发的读者适当地了解一下服务器开发的思路，反过来也建议从事后端开发去学习一下客户端开发，二者相得益彰。从个人的技术提高来说，也是很有帮助的。例如您要学习一套开源的软件代码，如果您熟悉客户端和服务器的基本开发和调试技巧，您可以更好地学习它。而在工作上，一个项目，往往是由客户端和服务器程序组成，如果您都熟悉，您可以站在一个更高的角度去审视它、规划它，这也是架构师的基本要求之一。

最后就是很多读者关心的客户端和服务器的薪资问题，这个没有绝对的谁高谁低，因人而异，因能力而异，因岗位而异。

如何看待 C++ 11/14/17 新标准

C++ 开发者有个不成文的规定就是，即使您对 C++ 很熟悉，也不要在简历上写上您精通 C++，原因很简单—— C++ 这门语言包含的东西实在太多了，没有人能真正“精通”所有。C++ 既支持面向对象设计（OOP），也支持以模板语法为代表的泛型编程（GP）。而且新的 C++ 标准和遵循 C++ 新标准的编译器也层出不穷，这些年，C++ 变化越来越大，越来越快，从最初业界和开发者翘首以盼的 C++11 标准，历经C++14、C++17 到今天的 C++20，这门语言与之前的版本差别越来越大，更多原来需要使用第三库的功能也被陆续添加到 C++ 标准库中。以致于C++之父 Bjarne Stroustrup 也开始对这门语言表示担忧：

在 C++11 开始的基础建设尚未完成，而 C++17 基本没有在使基础更加稳固、规范和完整方面做出改善。相反，却增加了重要接口的复杂度，让人们需要学习的特性数量越来越多。C++ 可能在这种不成熟的提议的重压之下崩溃。我们不应该花费大量的时间为专家级用户们（比如我们自己）去创建越来越复杂的东西。（还要考虑普通用户的学习曲线，越复杂的东西越不易普及。）

在Bjarne Stroustrup的信中，他担心C++会像历史的瓦萨号军舰一样，启航即沉没。

当然，我们不用有这种担忧，毕竟我们既不是 C++ 标准委员会成员，也不是 C++ 编译器开发厂商。就我个人经验来说，对于C++11、C++14、C++17乃至C++20，我们学习它们的准则应该是以实用为主，也就是说我们应该学习其实用的部分，至于新标准提到的一些高级特性和各种复杂的模板，我们大可不必去了解。我们并不是做学术研究，我们学习 C++ 是为了投入实际的生产开发，所以应该去学习 C++ 新标准中实用的语法和工具库。关于C++11常用一些知识点，这里也简单地给读者列举一下：

auto关键字、for-each循环、右值及移动构造函数 + std::forward + std::move + stl容器新增的emplace_back()方法、std::thread库、std::chrono库、智能指针系列(智能指针的实现原理一定要知道，最好是自己实现过)、线程库std::thread+线程同步技术库std::mutex/std::condition_variable/std::lock_guard等、lamda表达式（JAVA中现在也常常考察lamda表达式的作用）、std::bind/std::function库、  其他的就是一些关键字的用法(override、final、delete)，还有就是一些细节如可以像JAVA一样在类成员变量定义处给出初始化值。

C++语言基础与进阶

基础

这里说的基础不是狭义上的 C++ 语言基础，而是包括C++开发这一生态体系的基础，笔者认为的基础有：

C++语言本身熟练使用程度

前面也介绍了单纯的 C++ ，您必须结合一个具体的操作系统平台，所以您得熟悉某个操作系统平台的 API 函数，比如linux，以及该操作系统的原理。这里说的操作系统的原理不局限于您在操作系统原理图书上看的知识，而是实实在在与系统 API 关联起来的，如熟练使用各种进程与线程函数、多线程资源同步函数、文件操作函数、系统时间函数、窗口自绘与操作函数（这点针对Windows）、内存分配与管理函数、PE 或 ELF 文件的编译、链接原理等等。

网络通信，网络通信在这里具体一点就是socket编程。这里的socket编程不仅要求熟练使用各种网络 API 函数，还要求理解和灵活运用像三次握手四次挥手等各种基础网络通信协议与原理。关于 socket 编程实践，《TCP/IP网络编程》这本书是非常好的入门教材。

UI 部分

对于UI部分，我们的认识是这需要使用 Windows 的窗口技术。我们可以直接使用原生的 Win 32 API 来制作自己的界面库，也可以选择一些我们熟悉的界面框架，如mfc，wtl、duilib、wxWidgets等。无论您是在阅读别人的这样的项目还是需要自己开发这样的项目，在确定了这款软件使用的 UI 库（或者使用原生Win 32 API），您就需要对 Windows 的窗口、对话框、消息产生、派发与处理机制需要了解，同样的道理，如果不熟悉您需要补充相关的知识。