呵呵,那个帖子里面的意思不是为了说operator<<复杂,我那篇文章主要强调的是C++流输出对输入参数结束判断手段的缺失.那句"天哪"开头的抱怨,是指编译器在后面做了很多事情,要全部都了解到,代价太大.

  回复  更多评论
  

模板元就搞死很多人，所以我从来就不去了解它....
C++其实还是比较简单的，如果我们把一些不用的特性给忽略掉的话
其实很多人只是用到了C++的一个子集，很少人要把所有的C++特性
全搞明白。  回复  更多评论
  

TC++PL
2.9[2] You don’t have to know every detail of C++ to write good programs; §1.7.
24.5[2] Use C++ features and techniques as needed (only); §24.2.  回复  更多评论
  

@那谁
那你是指编译器偷偷干了什么事情……我记得会自动生成的函数只有构造函数、析构函数、复制构造函数和operator=。其他的都是去调用这4个函数而已。而且自动生成的这4个函数的内容也是调用成员的这4个函数，一直递归下去，其实也没做什么事情。  回复  更多评论
  

@chaogu
建议：学模板元编程之前，先学Haskell，效果显著，深入浅出……  回复  更多评论
  

@yrj
其实大部分复杂都是为了构造stl而搞出来的  回复  更多评论
  

复杂是相对的。
学习c++语言本身的时间 毫无疑问是比其他类似高级语言要长的。

c++将很多东西交给程序员来控制，
那么很自然的学习的时间就会增加。
程序员在开发的时候 放在语言本身的注意力就会增加，在很多人看来这是一种负担。毕竟大部分人在写的程序对效率要求是很低的，他们不需要对内存的严格控制对计算机中的事情了如指掌，他们只希望程序能跑起来而已。

每个人的看法是他所处的环境决定的，
技术就是技术，不了解的人对任何事物都觉得复杂，了解的人都觉得很简单，仅此而已  回复  更多评论
  

此帖必火。最后很可能成为又一轮语言大战。
我以前是C++/OO的狂热者，后来有变得不狂热。其他语言我熟的不多，就拿C做比较。
1、语法相对复杂，语法规则细节太多，越是懂得语法细节越多，写出的代码越是往复杂方向靠。记得我以前写过一篇牢骚贴（强大的BCB），那个移植我的C++代码到BCB编译器时所经历的编译除错，就整出了很多语法细节。尤其是参杂了模板的C++。我想，就我以前在C++上的努力而言，不算不懂乱说的人吧
2、带来的设计复杂，基本上C++会被捆绑到OO上，见到的C++库越多，了解的设计思想越多，自己做的设计也越来越倾向于复杂，我们的代码是否真的会面临这些变化？相比而言，在用C写库代码时，就非常直接，接口设计方式也很简单。  回复  更多评论
  

功能越多，提供的选择就越多，我想做的就越多，给我出错的机会就更多。但给牛人，用好的机会也更多。
在于如何使用，如何选择。
  回复  更多评论
  

@Kevin Lynx
我才不会挑起什么大战呢，这里就只谈C++，任何比较不同语言的帖子都会被我删掉的，谢谢。  回复  更多评论
  

@Kevin Lynx
个人认为，C++的库对于OO的涉及是很少的。由于纯虚类写起来花的字符比较多（这通常是程序员选择语法的一个重要依据），而且指针也不太方便，而且还有构造函数和析构函数，你会发现C++的库倾向于不使用继承，而是用“值类型”的方法来做。譬如STL的容器，复制的时候是会复制内容而不是句柄的，这根C#和Java等的不一样。

因此C++并不会捆绑到OO上，相反来说比其他的OO语言“更不鼓励”OO，而鼓励使用值类型。C++的程序比起其他的语言来说，写出那种一大堆接口和继承的概率还是要小的。因为C++可以更加自由地使用不同的范式，当然结合的最好的非combinator莫属了，这种OO+值类型+模板元编程混合而形成的declarative programming的类库，都是十分的好用（譬如boost::spirit，还有我写的那个）。  回复  更多评论
  

@键盘的咏叹调
我认为，C++的stl就是为了解决语言的复杂问题而产生的，结果很多团队因为怕自己的手下太烂，而且怕自己的手下没办法使用统一的编译器产生的binary，从而放弃异常（更甚者放弃RAII），结果导致STL没法用，才让那些程序猿处于水深火热之中加班的。如果大规模使用stl的话，很多问题都可以解决。

譬如说我听到为了禁止使用new而不用stl，殊不知stl还有Allocator，你可以写，实在不行还能重载全局的new/new[]/delete/delete[]/new()/new()[]/delete()/delete()[]呢，虽然比较危险。

C++的一个哲学就是让类库尽可能的提供功能，为了达到这个目标，不同的语法就必需尽可能正交，而且功能强大到到处都可以插入callback，从而写出高质量而且语法优美的类库了。所以正确的使用方法应该是大规模使用stl和boost，而不是直接使用C++去构造所有东西。  回复  更多评论
  

@陈梓瀚(vczh)
C++的一个哲学就是让类库尽可能的提供功能，为了达到这个目标，不同的语法就必需尽可能正交，而且功能强大到到处都可以插入callback，从而写出高质量而且语法优美的类库了。所以正确的使用方法应该是大规模使用stl和boost，而不是直接使用C++去构造所有东西。
====================================================
赞同，这段话让我想起了《C++ 沉思录》中说的：语言设计就是库设计，库设计就是语言设计。  回复  更多评论
  

我觉得只是复杂， 问题还不大。

C++的问题出在给出的特性分了岔。
从留言中就已经可以看出有（曾经）崇尚OO的，和不主张OO的两派。
当团队中人数再增加时， 肯定还会出现更多派系。
如果没能很好的控制， 就很难和谐， 造成四不像的设计。

相比而言， C和java都没这么容易分岔。
尤其是java， 团队中基本不会出现不兼容的设计， 因为没有什么其他的好的选择。
  回复  更多评论
  

@OwnWaterloo
C++号称支持4种编程范式，那显然是你想怎么做都可以了。但是在团队协作开发同一个组件的时候，接口都是要经过讨论的，提交代码前都要组员review的，设计文档写出来还要给其他相关组review的，足以防止这些问题了。我觉得不能把软件工程上的错误怪罪到C++头上来。

至于说选择多的东西交给一群没经验的人是会出问题的，那这不就证明他们要是能力不足或者不想学这么多东西，就应该去用C#和Java而不应该用C++吗。  回复  更多评论
  

复杂很大程度上是了解不够
常见情形：某个程序员对某个特性不慎了解，然后随意用了这个特性，编译、简单测试通过，提交代码完事。以后出现问题了，接着感叹下C++真复杂，然后改掉使用特性的代码。  回复  更多评论
  

@陈梓瀚(vczh)
讨论， review什么的， 有一些用处， 但不能全防住。
特别是"团队换人"的时候。

这些讨论不一定会被良好的记录。
新成员可能就乱来了。

如果是团队大换血， 可能新的团队就会觉得现有代码是坨屎。


>> 至于说选择多的东西交给一群没经验的人是会出问题的，那这不就证明他们要是能力不足或者不想学这么多东西，就应该去用C#和Java而不应该用C++吗。

没有经验、 能力不足、 不思进取、 混口饭吃的， 恰恰占大多数。
所以， C++也只是少数人手中的利刃， 不是谁都玩得转的。
一部分玩不转的人， 就把原因归咎到C++过于复杂。
推卸责任是很常见的心理。
  回复  更多评论
  

@airtrack

严重同意！  回复  更多评论
  

@OwnWaterloo
所以那些人坚持使用C++就是个错误嘛，有些东西还是C#和java来写更好一点。不过因此就说C++不好，显然是他们自己的错。  回复  更多评论
  

@陈梓瀚(vczh)
如果C++再提供一个"特性"： 可以禁用某些方面的另外的特性。
团队合作时会不会好一些？

比如看异常不爽的团队， 直接在构建脚本里， 通过编译选项把异常的使用给禁了。
看xxx不爽的， 也可以。。。
  回复  更多评论
  

我听过比较多的关于C++复杂的理论，主要集中在无法根据C++的代码，判断生成最终汇编代码的形式，而C不会有这个问题。很容易就能根据写的C代码，脑子里自动生成GCC O2级别的汇编。

关于C++的争议，最有水平的该是linus早期对其的一些评价。其中就有07年，著名的C++狗屎论：http://lwn.net/Articles/249460/

中文版：http://blog.csdn.net/turingbook/archive/2007/09/07/1775488.aspx

其中的有一段话很有趣：
C++会导致非常非常糟糕的设计选择。你们这些C++程序员总是一上来就用语言的那些‘漂亮的’库特性比如STL、Boost和其他彻头彻尾的垃圾，这可能对你们的程序有所‘帮助’，但是却会导致：

“——当库无法工作时无穷无尽的折磨（别跟我说什么STL尤其是Boost很稳定而且可移植性很好，那全是屁话，而且一点都不可笑）

"——低效的抽象编程模型，可能在两年之后你会注意到有些抽象效果不怎么样，但是所有代码已经依赖于围绕它设计的‘漂亮’对象模型了，如果不重写应用程序，就无法改正。

”也就是说，使用优秀的、高效的、系统级的和可移植的C++的唯一方式，最终还是限于使用C本身具有的所有特性。项目限制只用C，意味着参与的人不会捣乱，也意味着会得到许多真正懂得底层问题，而不会折腾那些白痴‘对象模型’垃圾的程序员。

  回复  更多评论
  

我发现我刚才发表的帖子 后半部分貌似例题了···，你讨论的是C++的复杂性，我写成了C++和C的优劣性。LZ和各位朋友请自动无视后面那部分。

不过，既然是讨论C++的复杂，那我要说句，确实太TMD的复杂了，我看到就头大·····  回复  更多评论
  

如果一个任务可以用一种简单的语言10分钟完成，
为什么我要去用c++ 花一个小时呢？

c++既然已经提供了这么多功能，光靠stl、boost、loki这些库 是指标不治本的，因为从还是不能从根源降低复杂度。而且即使是为了治标，泛型库也不得不使用更加晦涩难懂的语法。大家可以自己问下自己，从何时开始看到c++编译器提示的有关stl编译错误，不头大的？


至于linus说的 C++会导致非常非常糟糕的设计选择 我认为不过是哗众取宠罢了。任何语言都有其不可克服的缺点，只要你愿意你也可以拿asm把c数落得一无是处。

c++不可能赢得所有人的心，有的项目拿c++很适合，有的项目拿java更好，有的项目或许用vb来的更有效率。至于其他项目管理上的内容，或许各个公司是有各自的考虑的，毕竟从公司角度来说，减少无谓的开发风险是首要的，所以才有了各种千奇百怪的“代码规范”。


当然，c++标准如果总是十几年也不更新一下
或许随着硬件的不断发展，
止步不前的c++还会渐渐丧失用户

  回复  更多评论
  

c++的的“复杂”不仅仅在于语法的细节，而是在于”倾向于过分复杂的设计”；如果你是一个人做独立项目，会觉得C++像瑞士军刀一样爽，但是对于团队合作，我觉得C++是一个灾难性的语言。  回复  更多评论
  

“c++其实不适合做大规模可伸缩性的项目”，这话谁说的, Lippman —— MS VC的核心开发者，c++ primer的作者。  回复  更多评论
  

@OwnWaterloo
VC++可以禁用某些语法的……  回复  更多评论
  

@键盘的咏叹调
C++标准刚刚更新了啊，你怎么能说十几年不变呢  回复  更多评论
  

@wuqq
这是因为VC++没有实现一套好的ABI导致的。如果C++跟C#一样，所有代码都可以无缝放进dll然后结合，那么什么问题都没有了。  回复  更多评论
  

@wuqq
Windows的存在代表C++还是可以用来做超级巨大的事情然后又不会出灾难的- -b  回复  更多评论
  

@键盘的咏叹调
C++的那些stl和boost本质上就是在模拟其他语言的“语法”，所以你怎么能怪罪于他们“不能降低复杂度”呢。就如同一个没有反射的java，变成了有发射的java，也降低不了什么复杂度的。  回复  更多评论
  

可能是说比较容易出错。  回复  更多评论
  

@陈梓瀚(vczh)
不知道有没有人研究过Windows的源码，但是内核的开发，尤其不适合用C++，不需要过
  回复  更多评论
  

不知道有没有人研究过Windows的源码，但是内核的开发，尤其不适合用C++，不需要过多的抽象，不需要面向对象。很多应用，说是C++，其实只是C++一个很小的子集，披着C++外衣的C而已  回复  更多评论
  

@wuqq
这不是问题，一般来说披着C外衣的C++至少都包含构造函数和析构函数，而这两个东西对于让代码变得更加可维护是极端重要的，反而OO那些东西可以没有，构造函数和析构函数是一定要有的。  回复  更多评论
  

实际上《人月神话》的一个观点完全可以解释所谓的 C++ 的复杂性。该书认为一致性对软件非常重要。要保证一致性，我们并没有多少选择：或者在没有多少限制的前提下三五个人做一个东西；或者在严格限制的前提下数十人甚至上千人做一个大工程；此外就是以上两者之间广阔的灰色地带。

不做限制，很难保证一致性；限制太多，妨碍了创造性。限制本身在其被制定出来的时候，展现了一种停滞性，限制这个词的定义表明了限制本身的演化的迟缓性，这导致了相对的落后。可见限制的副作用是很大的。

但这是一个商业的世界。投资软件的目的是为了利润。在一个新兴的市场里，创新很重要。那么多的东东都还不成熟，还需要去探索。少数 C/C++ 的高手可以在其中大展拳脚。在一个成熟的市场里，似乎一切都那么四平八稳，控制成为了公司的追求。C/C++ 这么不好控制的东东，当然没落了。  回复  更多评论
  

@陈梓瀚(vczh)
控制for中的变量的scope？
还是禁用异常？
还有其他的么？  回复  更多评论
  

@OwnWaterloo
禁用RTTI等等。  回复  更多评论
  

@wuqq
很多网站使用asp写的，那么我们都不用c,c++,c#,java等等任何其他语言吧。  回复  更多评论
  

言之无物，纯粹是想骗评论的吧！  回复  更多评论
  

@frankt
摆明了不就是想要在评论讨论吗，何来之骗。  回复  更多评论
  

@陈梓瀚(vczh)
C语言虽然只是C++的一个子集，但是思维方式与C++完全不同，这也是很多人建议把它们看成两种语言的原因。而析构函数也就是一种管理资源的方式，大部分情况下都是内存管理，如果在C语言设计的应用中引入一种好的资源管理方式，会发现析构函数其实也不是那么重要。  回复  更多评论
  

丝毫不怀疑C++的复杂性，因为自己有时候也会掉到陷阱里。

但是我很怀疑：一个用C++时不停的犯错误，代码质量糟糕，或者在语言特性的框架之内经常感到一些功能实现不了的人如果转用了java，C#或者脚本语言，那么他写出的程序水平或者质量就能“自动”的上一个台阶么？

我不太相信这个。  回复  更多评论
  

所谓C++问题多，实际上还是程序员的问题。

以为自己很牛逼，语言的任何Feature都敢用。你不熟的Feature，用了不是找死咩？用出了问题，就开始怪C++。哦，你说你拉不出便便了，就能埋怨这洗手间太高档了咩？
  回复  更多评论
  

@空明流转
所以这就是业余项目造车轮的重要性啦，不造车轮，你怎么有机会用这些feature，怎么能让你的控制能力上一个台阶涅。  回复  更多评论
  

@欲三更
显然质量还是那么烂的，这个无需怀疑  回复  更多评论
  

@wuqq
问题就在这里嘛，用C实现好的资源管理，还不如C++的构造函数析构函数成本低又容易掌握，何必信仰纯C程序呢。  回复  更多评论
  

@陈梓瀚(vczh)
1）C++中的析构函数成本也并不一定比C低，要用析构函数，就必须考虑拷贝，考虑赋值，考虑引用，还有新引入的左值引用。
2）选择语言，首先要看做什么，再来选语言。但是，“C++绝对是最糟糕的选择。如果想要真正的高级特性，那就选择有垃圾回收或者好的系统集成的，而不是既缺乏C的简约又缺乏C的直接而且没有重要概念的高层绑定（high-level bindings to important concepts）的东西。” “C++既无法帮助原型化或者简单的GUI编程足够简化从而真正可用，又不是C那样积极地鼓励你使用简单和直接的语言构造的精益系统编程语言。“从现实来看，C++越来越限于某些领域，比如GUI，比如游戏开发。c++优秀的库并不多，boost是其中的经典，是最优秀的C++ 程序员开发出来的，但是，就这样，boost中优秀的库只是一小部分，大部分库仍然说得上是丑陋。
  回复  更多评论
  

每种语言都会施加它的限制，区别只是：一种是枷锁式的，一种是水对鱼的限制，一种是力不能及式的。有人认为 C＋＋带来心智负担，而 C 如何的简洁。实在很可笑，这就像是在歌颂力不能及式的限制，歌颂古代工匠的智慧同时鄙视现代化机器大生产。不管 C 如何的简洁和强大，C 的应用领域有多大呢？除了操作系统及其驱动，世上要写的程序千千万，操作系统却屈指可数。
  回复  更多评论
  

@wuqq
成本什么的，你觉得是开发成本重要还是运行成本重要啊。话说回来，C++析构函数的好处在于“我不用管”，从而不会轻易犯错。如果我要指定哪里要用构造函数析构函数哪里不用，那就回归到C了。而且调用析构函数也是个普通函数，跟你每次都掉一个函数去free完全没有区别（还更好，类型安全，异常安全）。

而且，因为“C++是最糟糕的选择”的同时，你不去选择C#和Java而选择C，这就“更加糟糕”了，不是吗。如果你觉得C已经足够好了，那显然使用C++会让你变得更轻松的同时，你也不会失去什么。所以这个理由完全是不成立的。

一般来说，我很建议人家使用C++的少部分特性，譬如说构造函数和析构函数。你愿意让编译器自动调用你的分配和释放函数好呢，还是你自己在程序的每一个地方都调用好呢。显而易见。而且C++你其实还能控制它对某个类不要产生构造函数和析构函数的（如果你是一个合格的程序员的话），因此完全无害。你认为呢，为啥使用C++就得去使用高级特性呢，掌控不了高级特性而去使用它才是愚蠢的，我认为仅仅使用构造函数和析构函数，也已经比C要好得多了。因为在我看来，在完成一个稳定的程序的同时，应该让语言帮助我避免绝大多数问题的同时我还能控制所有细节（非C++莫属了），而且我还不需要因为语言自动化程度太低而老是加班。

人的时间才是最宝贵的，如果你想让你的程序变得非常强大，你也不能因此让自己劳动时间延长太多，而应该果断选择生产力更高的语言。然后你只需要相信那些虚拟机做得足够好就行了。因为那些东西最终会被大公司维护，自动升级，你的所有程序都会得到好处。正所谓一口吃不成胖子，你想自己维护好呢，还是让一大堆大公司来帮助你维护好呢？不过使用C++，虽然的确是比Java和C#要麻烦一点，只要你是一个合格的程序员，那我相信绝对不会写得比C差的，最少都能跟C一样差，不会再差的了。如果你同时用C++和C写相同的一个程序，结果C++还用得比C差，那只能怪你自己了不是么。当然前提条件是，你只使用你熟悉的特性。  回复  更多评论
  

@wuqq
我从来不会觉得因为C++难用而选择C#或者Java有什么不对，但是你在需要新特性的同时，又不选择C#和Java（这才是真正的心智负担，我不信你的大部分代码都写得比人家的虚拟机和编译器要厉害），而且还是停留在C上，这才是最大的错误呢。除非你觉得C已经用的很爽而且不需要加班也能写出满足公司要求的程序这也就算了。

再次强调，人的时间才是最宝贵的。你永远都可以通过使用集群的库（譬如.net的Task和Parallel等，C语言不详），然后让用户砸钱购买机器组成集群，来使你的程序的性能大幅度提高的。你用C肯定没用户买新机器所带来的提高要显著，或者根本就没有提高。  回复  更多评论
  

1）我引用的是linus的的话，我不觉得这句话很容易引起误解嘛？ 那我再解释一下，这句话是话，要么你用低级的C，要么你用高级的Java, .net，python之类。
2）关于开发时间，对于现在的系统来说，很多都是多语言混搭的。c语言好处在于API简单，访问直接，适于构造专有模块。
3）我再引用linus的一句话吧：内存管理根本不是问题，重要的是设计。但愿不会引起误解。
  回复  更多评论
  

@陈梓瀚(vczh)
你好像强调了一点，“你只使用你熟悉的特性”——这个对于C++，一点不难，困难的在于你要保证：你的同事只使用你熟悉的特性  回复  更多评论
  

不是说语言之争无意义，而说说它很容易陷入无意义的争论。关于这个问题，我想换一个角度来思考：语言的选择对于系统设计的影响  回复  更多评论
  

@wuqq
这个命题有问题，我们应该根据目标系统来选择我们最合适的语言，然后让团队们认真学习。

保证没问题，每一次checkin之前都要review的，每一个critical的设计都有相应的负责人来review的，每一份开发文档都有相关team的人来review的，每设计一个产品的时候都有人保证如果你们的东西没有被review过那么就算写好了都不算的。

有了checkin之前的review，我就不信所有人的知识的并集都不能包含C++的常用特性。大部分时候都源于团队协作的方法不对——不肯花成本来保证开发质量，从而减少修bug的时间，从长远的角度来讲既可以提高成员的水平，也可以让项目的总时间变得更快。  回复  更多评论
  

@wuqq
那为啥用了java的人就没人想要去了解其细节，而C++就偏偏要呢？  回复  更多评论
  

不记得是在哪里看到的了，大意是：
一个优秀程序员要掌握的知识无论使用哪些语言都是差不多的，不同的地方在于：使用C++的话，你必须把它们大部都学会了，你才能动手做一些有实际意义的东西，（否则你将面临着一大堆的陷阱）。而Java/C#等，则可以把学习的“时间”平摊，在你没有“完全”掌握这些知识之前，你已经可以做一些实际的东西出来了（虽然这个时候还称不上是“优秀”的程序员）。
我觉得，C++所谓的复杂性，大约就是这样。
PS：把Java/C#放在这里并不想引起争论。但是我想，如果世界只有一门语言的话，大概没有谁会“抱怨”它的复杂性。要说它复杂，那是比起其它语言的“感觉”。所以，不比较是不可能的……好纠结  回复  更多评论
  

没有垃圾回收机制显的比较笨拙。现代程序员都被宠坏了，可以不计代价的申请资源，从不考虑性能问题，c/c++对他们来说显的太复杂了。  回复  更多评论
  

@唐风
当然不能不比较，但是比较的结果不能是哪个好哪个不好。  回复  更多评论
  

@kevin.c
那些程序猿们不是每天嚷嚷着C#和Java隐藏了太多特性么，有空研究这些的人不是正好应该使用C++么，而且他们又嚷嚷C++太复杂C简单，那说到底都是抱怨而已。  回复  更多评论
  

你不觉得C++的关键字太多了么?
想想Djikstra是怎么说的吧
  回复  更多评论
  

@狐说
好歹人家关键字都是B.S.大胡子当年考察用户习惯最终才定下来的，而且你用变量名的时候如果那玩意儿变蓝了，你不心慌么……你不会碰巧用到关键字的。

话说回来，不相用的你不去记住就行了，中文字也这么多，没人抱怨的……  回复  更多评论
  

@陈梓瀚(vczh)
不错：
不相用的你不去记住就行了，中文字也这么多，没人抱怨的  回复  更多评论
  

@陈梓瀚(vczh)
你大概没明白我的意思
Dijkstra的意思是, 如果一个语言解决问题的方式就是再增加几个关键字的话
是很有问题的  回复  更多评论
  

@狐说
关键字不是一切，重要的是语法。你看现在C#的关键字就很智能，如果某个地方不可能出现关键字的话，那个东西就会被分析为一个名字而不是关键字，多了也无所谓的。Dijkstra口中的关键字跟我们所理解的关键字不是一回事，所以还请你仔细体会体会。  回复  更多评论
  

@陈梓瀚(vczh)
2010-07-07 14:19
话说文中的重载应该是替换，在此同时也有重载。非对称性导致问题多多。在行为描述上更是奇葩，即使在允许的框架上去改变一下这些行为，感觉都挺蛋疼的。  回复  更多评论
  

很不错的思想  回复  更多评论
  

由于项目调研，看过V8引擎的代码，用C++写的，表示非常的漂亮，可是只是两个人的作品，对于项目人员较多或者人员变动较大，或者人员水平参差不齐的情况，不建议使用C++。  回复  更多评论
  

如果研究过ffmpeg的源码的话，就能理解C++的语言复杂性给我们带来的是何种便利。

第一，ffmpeg是C写的，没有办法从语言层面区分API暴露的函数、数据结构与内部使用的函数、数据结构，作者提供区分的唯一办法是写注释，如果用错了编译器不会保护你。

第二，ffmpeg的数据结构包括许多指向其他数据块的指针，导致非常复杂容易出错的初始化和清理工作，由于前一个问题，哪些部分该由调用者初始化和善后清理也是混沌不明的。我相信目前基于ffmpeg的绝大多数应用程序都或多或少存在着初始化和清理工作的bug。

第三，C语言难以使用基于线程安全的引用计数的内存管理方式，在多线程越来越重要的今天，多线程之间传递视频帧需要大量多余的memcpy。不是说C语言一定不能用refcount，就有一批参与开发者因为不满于ffmpeg原作者对refcount的保守态度，分出了一个Libav项目，但是原作者对此强烈抨击，认为这将是一场灾难。我也看了Libav的新API，用C语言操作引用计数的数据块真是很痛苦的。

第四，这或许是个细节问题，但是非常典型。ffmpeg的基本数据结构之一AVFrame，它的最前面是
uint8_t * data [AV_NUM_DATA_POINTERS];
int linesize [AV_NUM_DATA_POINTERS];
后面跟着许多细节数据，如width，height，format等等，但是很多函数却把它当成一个AVPicture来处理。AVPicture就是只有data和linesize这两块，后面的都没有。所以，无论ffmpeg内部，还是外部调用者，都需要反复在AVFrame*和AVPicture*之间来回转换。在我们熟悉C++的人看来，AVPicture明明就是AVFrame的基类，多么简单的关系。

总之，作为C++程序员，看着作者蛋疼地处理这些早已被C++解决了的麻烦事情，只能无奈地抱怨一句：他干嘛不用C++呢？  回复  更多评论