主题：随便说说c++的这次吵架 -- tom

C++是第一种可长期维护发展的高效语言。所以，特别实用于大系统长周期的开发和运用。

你说的其他选择，要么不够高效，要么不易发展维护。

至少有三种语言：

一，C++ is C

二，C++ is an OO language

三，C++ is a genetic programming language

有的童鞋觉得难，可能是没有看清楚这个问题。如果把这三种不同的语言风格混在一起，当然是既难学，又用不好了。

事实上在80年代OOP通过C++普及后，像对待C的面向过程一样，C++把OOP就当成一个子集遗产，继续向 Generic 前进，在新世纪又在template的基础上探索Functional。

C++目标一直是zero-overhead的抽象。这也是虚拟机进不了语言核心的主要原因。

C++的设计目标不是任何模式，这正是持续关注他的价值所在，任何新的模式一出来，就会有人用 C++ 实现出来，通过观察学习这些实现，深入理解这些模式，跟看师傅组装车一样。

从作为导火索的毕达哥拉斯三元数开始，肖恩说，写好毕达哥拉斯三元数，既要搞好得懂点数论，又要用好线性代数才能写出高效代码，你们俩的代码都不合格，明显上数学课打洋晃，搞什么搞，玩两小儿辩日么？

游戏青年大约是吐槽太嗨，提了几个肖恩不能忍的事

- iota()这种函数命名莫名其妙

- 程序员干活又快又省才是是硬道理(Goal of programmers is to ship, on time, on budget)。

- 标准委员会高高在上，不食肉糜自娱自乐，他们的声音没有被标准委员会听到

肖恩给他补了堂历史课和思想品德综合课。

iota()源自 APL(A Programming Language)，就是 A 语言。这门语言的的特点就是跟数学概念联系紧密。

STL 的设计深受影响，另外一个被其风格荼毒的语言是 MATLAB。没听说过 MATLAB 的工程师起立，面壁。

发明这个语言让 Ken Iverson 在 79 年抱走了图灵奖。“ι”作为希腊字母表中的第 9 把交椅，数学家们请来表征包含映射（inclusion map）。Ken 感受到了其中的隐秘联系，在 APL 中用 iota() 来生成一个连续的整数序列。除了 STL, google的 Go 语言也这样。不奇怪不是，Google 的名字都这么数学范，10 的 100 次方。

编程是一个行业。作为从业人员，提升本行业的水准是一项道德义务，越资深越牛掰，对这个社区的义务就越重。

履行义务的方式很多。带人，讲课，写书，参加社团，帮助开源都算。

必不可少的是，好好学习，天天向上。读一读论文，工作的时候多翻书参考。

年轻人，无知而无畏，不以为耻反以为荣，在历史悠久的中文是贬义词，我用英文给你港一遍。Not knowing the history of iota() should not be something to be proud of, but an embarrassment。

肖恩是说，得有荣誉感，干一行要爱一行，通过提高自己的来提高行业平均值。

写代码的人永远不能把握谁在用，人家怎么用。他自己的代码，就被广泛应用到从来没有预见过的场合，所以对 goal 肖恩下了个自己的定义:

A goal for a programmer has to be to look beyond the product they are shipping and recognize their obligation to create correct and efficient solutions and understand that their code may well endure, for good or bad（一个程序员的眼光应该超越实现当前产品的需求，认识到他们的义务是做出正确和高效的解决方案，他们的代码能久经考验）

ISO C++标准委员会不是一个一般意义上权力机构，基本上愿意交会费，愿意自己出时间，出酒店机票，出提案，每年全世界参加会议被专家巨细靡遗地评头论足，就可以申请加入。

所以参加标准委员会背景各异，有人以语言培训为生去了解最新进展，有人去代表公司利益，还有人去刷学术资历。包含公司代表在内（微软就多年不甩标准委员会搞一套自己的VC++, Herb进去后才扭转风气，积极参与），多少有些为了满足马斯洛模型顶层需求，通过为广大人民服务实现自我价值。

被影射成高高在上，何不食肉糜的官僚机构。肖恩说，里面的人除了一个人，那个发明了C++语言的Bjarne，有可能会有这个想法, 他不知道哪一个是为了收集别人的意见加入标准委员会的。如果想对语言的未来发展方向有发言权，那就带张凳子坐桌子边上。

(完）

看来老兄是行家,正好在这里问一下

我也是VC6+MFC时代学的c++,一直没有什么机会用.如果现在想要从老古董c++进化到现代c++,跟上潮流,有什么门径(书,网站,视频,或其他资源)可以推荐么?

谢谢.

不过我已经写了很久的 C++，所以比较能心平气和接受这一点。

现在回头看，从 MFC 开始学 C++, 绝对是个不幸的事。除了早期用TC++和C++ Builder完成过课堂作业，我真正严肃意义上的使用 C++ 是从 MFC 5.0 开始的。我是从MFC 5.0开始。

MFC自己本身是一个失败的设计，官方都承认这一点，如果你知道Afx代表什么，基本上就理解为什么他是失败的设计。但是因为 Windows 的成功，和其赵家人身份，从产品来说，是成功的，所以尤其不幸。

现在回头看，即使只限定在 MFC 和 C++ 之间，MFC只有对 C++ 的虐待和滥用，没有做对一件事情。MFC 里关于 C++ 的所有设计都是错的，包括匈牙利命名法，虽然这个主观一点。

我个人认为学习 C++，最好的参考

- Bjarne的书（比如 A Tour of C++，Programming: Principles and Practice using C++ (2nd edition), TCPL很深邃，不过有点过时)，所有访谈(他的所有访谈都很很深刻)，和演讲录像，这些在他的个人主页上都有链接。

- 学习一下 STL, 比如 Nicolai M. Josuttis: The C++ Standard Library

- 学习一下 BOOST，Boost的文档写的很好，我个人觉得最好的是每一个库开始 rationale

- CPPCon, CPPNow，所有的PPT在github上有，video在youtube上都有。墙内微软的channel 9上有2017年以前的cppcon录像， 2018年在bilibili有。

- Twitter上关注一些CPPCon, CPPNow上的名人

以 C++ 的广度，深度和复杂度和反人类的本质，建议不要以学会 C++ 为目标。根据自己的兴趣，时间和实际需要，学一点是一点。

说 C++ 反人类，是如果把 C++ 看作人（程序员）和资源（电子系统）的桥梁，他的全部目标就是最优化资源的利用，以人付出更多为代价。Python刚好是另一个极端。做好两个一起学。Bjarne就说，一个人至少应该掌握两种计算机语言。

最后一点，学习任何计算机语言，最好用英文，主要是因为术语。翻译的书分分钟带你到沟里，而且，当你有问题的时候，你发现没法有效在网上提问。

比如我曾经很多年不明白sizeof()为什么是操作符，明显是个单词不是"符号"，如果一开始看英文，operator一词基本上不可能产生这种理解障碍。中间损失的脑细胞和自信心完全是翻译的锅。

偶就是从 c 开始，被其强大，简洁，直接，粗暴所吸引。

而后引入OO，进入c++。从封装，到继承，再到多态。

然后就一下子进入Generic编程。

再然后才是使用STL。。。

这一晃25年过去了。

因为一开始是从图像解码/编码，算法以及硬件操作进入的，倒没怎么被MFC带歪过。1999年到微软研究院实习的时候，写界面要用MFC，用了两个礼拜，受不了其繁琐和复杂，干脆在 win32API 的基础上做了个自己的c++库，一直修修改改用到今天。

本人非码农，只是用 c，c++，fortran，Java，Python，Matlab 而已。

MFC是我接触到的第一个application framework (当时是这么叫的,不知道现在还是不是这个概念). 我也是从MFC4.2开始的(此处捉个小虫:MFC没有5.0版,VC++5.0配用的MFC4.2直接跳道VC++6.0配用的MFC6.0).用C++的类把windows的消息循环封装起来,还觉得挺震撼的,当时费了不少功夫学,为什么从设计上讲是错的呢?

另外为什么连匈牙利命名法都是错的呢?

多谢了.

我其实是想说VC++5.0。我是觉得说MFC 5.0的时候有点别扭。

Visual Studio， C++编译器， COM的版本一直不一致。

MFC一开始是想做一Windows下的应用程序框架，所以一开始命名很多Afx的宏和类名。Stephen（就是那个把鲍尔默从Vista拯救出来，领导Win 7, 后来有功高震主被开的那个） 回忆说，他们一开始一直想着是怎么把 C++ 的所有特性功能都用上（那时C++还是很fancy，很酷，也没标准化）。直到项目一再延期，他们才认识到他们是在开发一个产品而不是展现语言功能。

MFC在OOP封装上是很失败的,可以说完全没有封装好，处处漏风，类之间的耦合很紧，到处是内部实现的泄露，导致一不小心就GDI资源或者内存泄漏。基本上徒有OOP的外表而没有实质。我猜C++内存泄漏的名声很大部分是MFC的功劳。估计很大一部分人第一次听说内存泄漏都是写MFC程序的时候。

MFC目标是一个应用程序框架，实际上因为功能不完整，也半途而废，最终基本是一个GUI框架。比如你说的消息传递机制，实际上只在写GUI窗口的时候用上。

而就它的实际作为GUI功能而言， WTL的设计要好的多，封装上有一致性，拥不拥有资源从命名上很清楚，实现简单，十来个header文件。google chrome 的 windows 版，大多数杀毒软件的界面，VMWare这些都是基于WTL。

匈牙利命名法错误在于把变量类型嵌入到变量命名，导致阅读困难，也难扩展（除了POD，类型缩写因人而异），而且重构也不变，把一个变量比如一开始用整型表示一个Id：int iId，后来重构到类ID后：ID iId会显得莫名其妙。

我们现在以穿越的形式，说它一无是处，不是因为吃饱了打厨子，是总结经验教训， MFC的毛病很大程度上是历史局限性，那时C++还没标准化，纯OOP的语言也没有（现在有了C#, .NET API的封装好多了）。

西河难得的C++贴，C++确实博大精深，大型项目中也用，但一定要控制好特性范围。团队中大家水平参差不齐，放开了用很容易导致灾难。

这个是在里面滚来滚去，洗过澡的，哈哈

我接手项目的时候对C和C++一无所知，现学现卖的，那个项目做了两年，恩，现在应该是在通信行业用了很久很久了，还在用。

先被打发去做前端，用了VC6，写了一个月吧，基本上按照前人的套路也能有模有样了，结果后端缺人，于是去写后端，还是Alpha小型机那个玩意，傻乎乎的以为差不多啊，哈哈，结果发现MFC这啥玩意啊，没有比较就没有伤害啊。

运气不错，在很短的时间内，不同的C/C++都轮了一遍，尤其是后来遇到STL，对开发的帮助很大

如果对C++ 11以上有一定了解，Moden Effective C++也可以考虑

早期主要都是windows应用开发.界面和数据库基本是主力了. 软件项目也不复杂. 界面开发和数据库对于新手来说,降低入门难度就MFC和BCB了.

有选择吗? 没有选择. 人坑很多年.写的程序一大堆.发现还是没学会C++. 哈哈

如果当初从linux起步,那C++估计玩的很溜了.