喂熊防窥。

http://www.zhihu.com/question/19721380/answer/14391649
当年猴话又被挖上来了，那么一并婊。从中可以看出一贯的智硬之处。而且，果然眼熟的也就是那么几只。
展示猴戏的目的主要还是在于警告意义。
```
冯东，C++ is an overcomplexity generator.
Xi Yang、卿培、知乎用户 等人赞同
学习面向对象概念是没有问题的。特别是 Java 纠正了 C++ 的几个问题：
面向对象必须有 GC（root-tracing GC 或者 reference-counting）。否则，几乎不可能写出没有严重的 use-after-release 问题的 app。而且会鼓励 value-copy 语义。
面向对象要避免 value-copy 语义，进而要避免在 stack 上构建对象。Value-copy 和在 stack 上构建对象会破坏对象的封装性，因为对象的使用者必须了解对象的内存布局。
但是面向对象本身是一个有漏洞的概念，特别是用实现继承来实现 reuse 和多态这种 class-based 方式。这个就得多借鉴几种语言了，比如 JavaScript 的 prototype-based 和 C 的直接函数指针多态。
```
除了最后一句以外全部是逗比……一眼过去的看点在于，最后一句看来是对OO大彻大悟了，然而前面的论调怎么看都是自愿摔倒谭×等级的沟里去了……
这样胡诌对象的含义，有些好奇Alan Kay听说后会作何感想。
GC和面向对象当然没几毛钱关系，McCarthy大约该表示呵呵呵……？
这里硬要说和“对象”有关系，也就是资源管理的抽象。
然而典型的GC恰恰是牺牲deterministic性质换来的不靠谱炸妈来换取特定情况下的性能（当然更主要的作用是缓冲智商欠费），显然更绥靖更靠不住use-after-release。
区别在于，没有UB，炸起来不干不脆更喜欢卡翔而不是崩溃就是了。
至于所谓避免value-copy语义是荣登猴子分类的显著笑话之一。是不是需要copy一个value，难道不应该根据解决问题需要确定？
非得不限定场景，value-copy反而因为可以避免/容易发现共享不确定的资源以及隐藏混乱的所有权和引用错误而应该是默认策略。到处引用说到底也就是把所有权扔给“全局对象”上去了（这里就是GC）。
这只能说是猴子等级的anti pattern。
然而更好笑的还在后面——“stack构建对象”——拿到现在来说就是个见怪不怪典型拿实现偷换接口语义的叒渣姿势罢了，我总是奇怪为什么偏偏就是那么多猴子好这一口。
这样的猴子，大概就不用指望对活动记录啊逃逸分析啊之类的常识有个大概理解了——连需求在哪都不知道：为什么需要栈？
通过限定资源生存期来避免浪费是个很显然的做法。然而GC厨嘛在这里一如既往没有困难也要给用户添乱。
按照之后的惯例姿势可能就该嚷嚷“内存就是拿来用的”（潜意识意淫“不随便我用内存就浪费”了），呵呵呵……按下不表。
事实上Value-copy 和在 stack 上构建对象并没有半毛钱依赖关系。这个槽点不表，“会破坏对象的封装性”也是个猴子层次的笑话，一看就不知道啥是对象啥叫封装。
C/C++及其实现的对象模型所谓的“对象”，和“面向对象”所谓的“对象”根本两码事，两者只是在实现上偶然同一，这个常识都不知道还能鼓噪而没被拆穿，不愧是逼乎……
“必须了解对象的内存布局”这种低级谣言也该不攻自破了——到底谁需不需要了解难道不是接口作者说了算？
API顺带夹杂ABI私货嘛，自觉去死就好了。

```
李遥
论据1&2说的特别好，100%赞同！
其实C++的几个倒霉特性就是从exception开始的：
Exception -> 没有GC的话一定会泄露资源 -> 所以用RAII模式 -> 所以要用模板来实现“智能指针”来包装一切资源 -> 干脆把标准库都用模板写得了 -> 今天的悲剧
```
果然物以类聚……
每一个“->”似乎都展示了猴子对人类逻辑的逗比诠释。
除了“RAII模式”这样的猴言猴语……连“智能指针”和模板写标准库的顺序这种历史常识都能搞反，也只能说是脸皮问题了。
```
Xi Yang
强烈赞成。C++居然要把对象声明的细节完全暴露在头文件里，作为API的一部分。
本来，我自己修改一个private成员，关用户什么事？但是因为涉及了对象尺寸、布局，就必须暴露出来。太恶心了。。。
```
看起来又是个不懂怎么找到接口责任的活该逗比上当者。
这个不需要单独评论，不过我忍不住好奇了，为啥连 PImpl idiom 都想象不到的程度（说不定啥叫 complete type 都不知道），精力却能支撑得了不去寻找问题的做法，直接大言不惭上蹿下跳呢……
关于对象布局这个坑以及可移植接口无能这点先不论，但直接把“提供让用户选择是否允许依赖对象布局”脑补成“必须暴露”，这未免也太下作了一点。
事实上，反过来不如说，必须隐藏对象布局的无能造成的现实问题连个变通都没有，那才叫拙计。
这种给予用户的设计相对于拙计的后者是 pure gain 。这点入门常识我到处都有见过有人科普（比如 ChinaUnix 的 OwnWaterloo ），但是逼乎例外。……轮子哥忽悠效率太低？这我就不深究了。
当然，是针对对于负责任的人类用户来讲的。如果是不懂接口目的的猴子，那么自然也没办法了。
……诶，为啥猴子码的要人消化擦屁股呢？
```
pansz，欢迎评论
合适，甚至来说，Java 比 C++ 更合适。因为 C++ 并不是完全面向对象的。而 Java 算是。 虽然严格的说我认为动态语言才能算是真正面向对象。不过动态语言往往意味着排错只能在运行期间进行，而这对程序员的技能和统筹规划能力有更大的考验。
```
都什么年代了还有人拿上面的猴子都看穿混乱的所谓纯 OOP 卖弄风骚……干脆就当猴子了么。
PS.下面一个明显更正常的回答却垫底，该说是不愧逼乎么。
EOF