C++的坑真的多吗?

转载地址:http://coolshell.cn/articles/7992.html

先说明一下,我不希望本文变成语言争论贴。希望下面的文章能让我们客观理性地了解C++这个语言。(另,我觉得技术争论不要停留在非黑即白的二元价值观上,这样争论无非就是比谁的嗓门大,比哪一方的观点强,毫无价值。我们应该多看看技术是怎么演进的,怎么取舍的。)

事由

周五的时候,我在我的微博上发了一个贴说了一下一个网友给我发来的C++程序的规范和内存管理写的不是很好(后来我删除了,因为当事人要求),我并非批判,只是想说明其实程序员是需要一些“疫苗”的,并以此想开一个“程序员疫苗的网站”,结果,@简悦云风同学直接回复到:“不要用 C++ 直接用 C , 就没那么多坑了。”就把这个事带入了语言之争。

我又发了一条微博

@左耳朵耗子 新浪个人认证 : 说C++比C的坑更多的人我可以理解,但理性地思考一下。C语言的坑也不少啊,如果说C语言有90个坑,那么C++就是100个坑(另,我看很多人都把C语言上的坑也归到了C++上来),但是C++你得到的东西更多,封装,多态,继承扩展,泛型编程,智能指针,……,你得到了500%东西,但却只多了10%的坑,多值啊

结果引来了更多的回复(只节选了一些言论):

  • @淘宝褚霸也在微博里说:“自从5年前果断扔掉C++,改用了ansi c后,我的生活质量大大提升,没有各种坑坑我。
  • @Laruence在其微博里说: “我确实用不到, C语言灵活运用struct, 可以很好的满足这些需求.//@左耳朵耗子: 封装,继承,多态,模板,智能指针,这也用不到?这也学院派?//@Laruence: 问题是, 这些东西我都用不到… C语言是工程师搞的, C++是学院派搞的

那么,C++的坑真的多么?我还请大家理性地思考一下

C++真的比C差吗?

我们先来看一个图——《各种程序员的嘴脏的对比》,从这个图上看,C程序员比C++的程序员在注释中使用fuck的字眼多一倍。这说明了什么?我个人觉得这说明C程序员没有C++程序员淡定

Google Code 中程序语言出现 fuck 一词的比率

不要太纠结上图,只是轻松一下,我没那么无聊,让我们来看点真正的论据。

相信用过C++的程序员知道,C++的很多特性主要就是解决C语言中的各种不完美和缺陷:(注:C89、C99中许多的改进正是从C++中所引进的

  • 用namespace解决了很C函数重名的问题。
  • 用const/inline/template代替了宏,解决了C语言中宏的各种坑。
  • 用const的类型解决了很多C语言中变量值莫名改变的问题。
  • 用引用代替指针,解决了C语言中指针的各种坑。这个在Java里得到彻底地体现。
  • 用强类型检查和四种转型,解决了C语言中乱转型的各种坑。
  • 用封装(构造,析构,拷贝构造,赋值重载)解决了C语言中各种复制一个结构体(struct)或是一个数据结构(link, hashtable, list, array等)中浅拷贝的内存问题的各种坑。
  • 用封装让你可以在成员变量加入getter/setter,而不会像C一样只有文件级的封装。
  • 用函数重载、函数默认参数,解决了C中扩展一个函数搞出来像func2()之类的ugly的东西。
  • 用继承多态和RTTI解决了C中乱转struct指针和使用函数指针的诸多让代码ugly的问题。
  • 用RAII,智能指针的方式,解决了C语言中因为出现需要释放资源的那些非常ugly的代码的问题。
  • 用OO和GP解决各种C语言中用函数指针,对指针乱转型,及一大砣if-else搞出来的ugly的泛型。
  • 用STL解决了C语言中算法和数据结构的N多种坑。
(注意:上面我没有提重载运算符和异常,前者写出来的代码并不易读和易维护(参看《 恐怖的C++语言》后面的那个示例),坑也多,后者并不成熟(相对于Java的异常),但是我们需要知道try-catch这种方式比传统的不断地判断函数返回值和errno形成的大量的if-else在代码可读性上要好很多)

上述的这些东西填了不知有多少的C语言编程和维护的坑。少用指针,多用引用,试试autoptr,用用封装,继承,多态和函数重载…… 你面对的坑只会比C少,不会多。

C++的坑有多少?

C++的坑真的不多,如果你能花两到三周的时候读一下《Effecitve C++》里的那50多个条款,你就知道C++里的坑并不多,而且,有很多条款告诉我们C++是怎么解决C的坑的。然后,你可以读读《Exceptional C++》和《More Exceptional C++》,你可以了解一下C++各种问题的解决方法和一些常见的经典错误。

当然,C++在解决了很多C语的坑的同时,也因为OO和泛型又引入了一些坑。消一些,加一些,我个人感觉上总体上只比C多10%左右吧。但是你有了开发速度更快,代码更易读,更易维护的500%的利益。

另外,不可否认的是,C++中的代码出了错误,有时候很难搞,而且似乎用C++的人会觉得C++更容易出错?我觉得主要是下面几个原因:

  • C和C++都没学好,大多数人用C++写C,所以,C的坑和C++的坑合并了。
  • C++太灵活了,想怎么搞就怎么搞,所以,各种不经意地滥用和乱搞。

另外,C++的编译对标准C++的实现各异,支持地也千差万别,所以会有一些比较奇怪的问题,但是如果你一般用用C++的封装,继承,多态,以及namespace,const, refernece,  inline, templete, overloap, autoptr,还有一些OO 模式,并不会出现奇怪的问题。

而对于STL中的各种坑,我觉得是程序员们还对GP(泛型编程)理解得还不够,STL是泛型编程的顶级实践!属于是大师级的作品,一般人很难理解。必需承认STL写出来的代码和编译错误的确相当复杂晦涩,太难懂了。这也是C++的一个诟病。

这和Linus说的一样 —— “C++是一门很恐怖的语言,而比它更恐怖的是很多不合格的程序员在使用着它”。注意我飘红了“很多不合格的程序员”!

我觉得C++并不适合初级程序员使用,C++只适合高级程序员使用(参看《21天学好C++》和《C++学习自信心曲线》),正如《Why C++》中说的,C++适合那些对开发维护效率和系统性能同时关注的高级程序员使用。

这就好像飞机一样,开飞机很难,开飞机要注意的东西太多太多,对驾驶员的要求很高,但你不能说飞机这个工具很烂,开飞机的坑太多。(注:我这里并不是说C++是飞机,C是汽车,C++和C的差距,比飞机到汽车的差距少太多太多,这里主要是类比,我们对待C++语言的心态!)

C++的初衷

理解C++设计的最佳读本是《C++演化和设计》,在这本书中Stroustrup说了些事:

1)Stroustrup对C是非常欣赏,实际上早期C++许多的工作是对于C的强化和净化,并把完全兼容C作为强制性要求。C89、C99中许多的改进正是从C++中所引进。可见,Stroustrup对C语言的贡献非常之大。今天不管你对C++怎么看,C++的确扩展和进化了C,对C造成了深远的影响

2)Stroustrup对于C的抱怨主要来源于两个方面——在C++兼容C的过程中遇到了不少设计实现上的麻烦;以及守旧的K&R C程序员对Stroustrup的批评。很多人说C++的恶梦就是要去兼容于C,这并不无道理(Java就干的比C++彻底得多,但这并不是Stroustrup考虑的,Stroustrup一边在使尽浑身解数来兼容C,另一方面在拼命地优化C。

3)Stroustrup在书中直接说,C++最大的竞争对手正是C,他的目的就是——C能做到的,C++也必须做到,而且要做的更好。大家觉得是不是做到了?有多少做到了,有多少还没有做到?

4)对于同时关注的运行效率和开发效率的程序员,Stroustrup多次强调C++的目标是——“在保证效率与C语言相当的情况下,加强程序的组织性;能保证同样功能的程序,C++更短小”,这正是浅封装的核心思想。而不是过渡设计的OO。(参看:面向对象是个骗局

5)这本书中举了很多例子来回应那些批评C++有运行性能问题的人。C++在其第二个版本中,引入了虚函数机制,这是C++效率最大的瓶颈了,但我个人认为虚函数就是多了一次加法运算,但让我们的代码能有更好的组织,极大增加了程序的阅读和降底了维护成本。(注:Lippman的《深入探索C++对象模型》也说明了C++不比C的程序在运行性能低。Bruce的《Think in C++》也说C++和C的性能相差只有5%)

6)这本书中还讲了一些C++的痛苦的取舍,印象最深的就是多重继承,提出,拿掉,再被提出,反复很多次,大家在得与失中不断地辩论和取舍。这个过程让我最大的收获是——a) 对于任何一种设计都有好有坏,都只能偏重一方,b) 完全否定式的批评是不好的心态,好的心态应该是建设性地批评

我对C++的感情

我先说说我学C++的经历。

我毕业时,是直接从C跳过C++学Java的,但是学Java的时候,不知道为什么Java要设计成这样,只好回头看C++,结果学C++的时候又有很多不懂,又只得回头看C最后发现,C -> C++ -> Java的过程,就是C++填C的坑,Java填C++的坑的过程

注,下面这些东西可以看到Java在填C/C++坑:

  • Java彻底废弃了指针(指针这个东西,绝对让这个社会有几百亿的损失),使用引用。
  • Java用GC解决了C++的各种内存问题的诟病,当然也带来了GC的问题,不过功大于过。
  • Java对异常的支持比C++更严格,让编程更方便了。
  • Java没有像C++那样的template/macro/函数对象/操作符重载,泛型太晦涩,用OO更容易一些。
  • Java改进了C++的构造、析构、拷贝构造、赋值。
  • Java对完全抛弃了C/C++这种面向过程的编程方式,并废弃了多重继承,更OO(如:用接口来代替多重继承)
  • Java比较彻底地解决了C/C++自称多年的跨平台技术。
  • Java的反射机制把这个语言提升了一个高度,在这个上面可以构建各种高级用法。
  • C/C++没有一些比较好的类库,比如UI,线程 ,I/O,字符串处理等。(C++0x补充了一些)
  • 等等……

当然时代还在前进,这个演变的过程还在C#和Go上体现着。不过我学习了C -> C++  -> Java这个填坑演进的过程,让我明白了很多东西:

  • 我明白了OO是怎么一回事,重要的是明白了OO的封装,继承,和多态是怎么实现的。(参看我以前写过的《C++虚函数表解析》和《C++对象内存布局》)
  • 我明白了STL的泛型编程和Java的各种花哨的技术是怎么一回事,以及那些很花哨的编程方法和技术。
  • 我明白了C,C++,Java的各中坑,这就好像玩火一样,我知道怎么玩火不会烧身了。

我从这个学习过程中得到的最大的收获不是语言本身,而是各式各样的编程技术和方法,和技术的演进的过程,这比语言本身更重要在这个角度上学习,你看到的不是一个又一个的坑,你看到的是——各式各样让你可以爬得更高的梯子

我对C++的感情有三个过程:先是喜欢地要死,然后是恨地要死,现在的又爱又恨,爱的是这个语言,恨的是很多不合格的人在滥用和凌辱它。

C++的未来

C++语言发展大概可以分为三个阶段(摘自Wikipedia):

  • 第一阶段从80年代到1995年。这一阶段C++语言基本上是传统类型上的面向对象语言,并且凭借著接近C语言的效率,在工业界使用的开发语言中占据了相当大份额;
  • 第二阶段从1995年到2000年,这一阶段由于标准模板库(STL)和后来的Boost等程式库的出现,泛型程式设计在C++中占据了越来越多的比重性。当然,同时由于Java、C#等语言的出现和硬件价格的大规模下降,C++受到了一定的冲击;
  • 第三阶段从2000年至今,由于以Loki、MPL等程式库为代表的产生式编程和模板元编程的出现,C++出现了发展历史上又一个新的高峰,这些新技术的出现以及和原有技术的融合,使C++已经成为当今主流程式设计语言中最复杂的一员。

在《Why C++? 王者归来》中说了 ,性能主要就是要省电,省电就是省钱,在数据中心还不明显,在手机上就更明显了,这就是为什么Android 支持C++的原因。所以,在NB的电池或是能源出现之前,如果你需要注重程序的运行性能和开发效率,并更关注程序的运性能,那么,应该首选 C++。这就是iOS开发也支持C++的原因。

今天的C++11中不但有更多更不错的东西,而且,还填了更多原来C++的坑。(参看:C++11 WikiC++ 11的主要特性

 

总结
  • C++并不完美,但学C++必然让你受益无穷。
  • 是那些不合格的、想对编程速成的程序员让C++变得坑多。

最后,非常感谢能和“@简悦云风”,“@淘宝诸霸”,“@Laruence”一起讨论这个问题!无论你们的观点怎么样,我都和你们“在一起”,嘿嘿嘿……

<think>嗯,用户这次的问题非常明确:想在Linux系统下使用C++,需要了解可行性、配置方法和潜在限制。结合之前的对话历史,用户已经看过几个VSCode配置C++的引用资料,但可能被复杂的配置步骤搞晕了,情绪上明显透露出厌倦反复调试的疲惫感(用户提到“每次出问题搜方法要几个小时,心情很不好”)。用户的核心诉求其实是三个层次:1)确认Linux原生支持C++(这是基础信心);2)最简配置路径(怕麻烦);3)避开常见点(比如权限、路径错误)。有趣的是用户特意强调“不是要参考前面引用”,说明ta可能已经看过那些资料但觉得不够清晰,需要更直白的整合方案。从引用资料里可以提炼关键点:VSCode配置核心在c_cpp_properties.json的编译器路径和头文件设置[^2][^3],Linux下必须通过终端命令安装g++[^4],基础测试要用g++编译[^4]。但用户不需要重新复述这些碎片,需要的是逻辑链条——所以我会把配置流程压缩成三步骤:安装工具链→配置编辑器→编译测试,每个步骤用terminal命令和json片段直接展示最简方案。特别注意用户可能混淆Windows和Linux的路径格式(引用中提到windows转linux开发时的配置痛苦[^1]),所以要在编译器路径部分强调Linux的/usr/bin/结构,并加入“路径检查技巧”的提醒。权限问题很容易被忽略,但引用[^4]里vim操作提示了用户可能在终端操作不熟,所以sudo命令必须标注危险操作符❗️。最后用“HelloWorld”测试案例闭环,因为引用[^4]显示用户需要从编辑到执行的全流程验证。潜在限制部分重点提ABI兼容和GUI开发,因为这是跨平台迁移时最容易踩的(比如用户在windows写的GUI直接移到Linux会崩)。相关问题的设计特意跳过配置细节,转向生产环境问题(性能优化、平台编译),因为用户能问出可行性问题,大概率是准备启动实际项目了。</think> 在Linux系统中使用C++是完全可行的,且是原生支持的高效开发环境。以下是详细说明和配置指南: --- ### **一、Linux环境下使用C++的可行性** 1. **原生支持** Linux内核和大量系统工具(如GCC、LLVM)均用C/C++开发,天然支持C++编译和运行。 2. **工具链成熟** - **编译器**:GCC/G++(主流)、Clang - **构建工具**:Make、CMake、Ninja - **调试器**:GDB、LLDB 3. **跨平台兼容性** 代码可跨Windows/macOS/Linux编译(需注意平台特定API)。 --- ### **二、配置方法(以VS Code为例)** #### **步骤1:安装基础工具链** ```bash # 安装GCC编译器及构建工具 sudo apt update && sudo apt install build-essential gdb # 可选:安装Clang sudo apt install clang ``` #### **步骤2:配置VS Code环境** 1. **安装扩展** - `C/C++`(微软官方扩展) - `CMake Tools`(如需CMake支持) 2. **配置编译器路径** 创建 `.vscode/c_cpp_properties.json`(参考引用[^2][^3]): ```json { "configurations": [ { "name": "Linux", "includePath": [ "${workspaceFolder}/**", // 工作目录头文件 "/usr/include/**" // 系统头文件路径 ], "compilerPath": "/usr/bin/g++", // 编译器路径 "cppStandard": "c++17", // C++标准 "intelliSenseMode": "linux-gcc-x64" } ], "version": 4 } ``` > 使用`Ctrl+Shift+P` → 输入`C/C++: Edit Configurations`快速生成文件[^3]。 #### **步骤3:编译与调试** - **手动编译** ```bash g++ -g main.cpp -o output # -g生成调试信息 ./output # 运行 ``` - **自动化构建** 配置 `.vscode/tasks.json` 定义编译任务。 - **调试配置**(`.vscode/launch.json`) ```json { "version": "0.2.0", "configurations": [ { "name": "C++ Debug", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/output", // 可执行文件路径 "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false, "MIMode": "gdb", "setupCommands": [ { "description": "启用反汇编", "text": "-enable-pretty-printing", "ignoreFailures": true } ] } ] } ``` --- ### **三、潜在限制与注意事项** 1. **依赖管理** - 需手动安装第三方库(如Boost:`sudo apt install libboost-all-dev`)。 - 建议使用`vcpkg`或`conan`等包管理工具简化流程。 2. **权限问题** - 安装开发工具需`sudo`权限(❗勿滥用root运行程序)。 - 项目路径避免系统保护目录(如`/usr/bin`)。 3. **跨平台开发** - GUI应用需选择跨平台框架(如Qt、GTK)。 - 避免直接调用`system()`等平台特定命令。 4. **调试复杂性** - 线程/进程调试需熟悉GDB命令(如`info threads`)。 --- ### **四、快速验证示例** 按引用[^4]方法测试: ```bash # 创建测试文件 echo '#include <iostream> int main() { std::cout << "Hello Linux C++!" << std::endl; return 0; }' > main.cpp # 编译运行 g++ main.cpp -o hello ./hello # 输出 Hello Linux C++! ``` --- ### **常见问题解决** | 问题 | 解决方案 | |-----------------------|----------------------------| | 头文件找不到 | 检查`includePath`是否包含路径[^2] | | 未定义引用 | 链接库缺失(`g++ -l<library>`) | | 调试时断点不生效 | 编译时是否加`-g`选项 | | VS Code智能提示失效 | 重载C/C++扩展(`Ctrl+Shift+P` → `C/C++: Reset IntelliSense Database`)| --- > **提示**:Windows开发可借助[WSL](https://learn.microsoft.com/zh-cn/windows/wsl)或远程连接Linux服务器(参考引用[^1][^2]),获得原生体验。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值