@vivagonna 鹅厂能清理门户么……

@Quaintjade 散光习惯脑补了就没那么计较了……-3 个柱镜度表示无所谓，凑近了顶多看清像素点，看个字整体仍然横竖都糊，必须后处理……

@gdtv 不清楚你这样说的理由。
我是经常顶着-8 个屈光度 10cm 盯各种屏幕的，并没觉得 300ppi 有什么不妥。大概是习惯了吧。
ppi 太高，早些年一不小心就容易激活强迫症凑近直到看清像素点……太不健康了。
倒是各种非阴暗背景下的 hinting 在 ppi 不够高的时候始终看得很不爽。然而这主要出现在盯着 PC 看的时候；一般意义上的 300ppi 仍然大体足够。

@bombless 题主最缺的就是泛型……
@q397064399 你什么路由器硬件配置那么痤……我这里 ARM946E-S 67MHz + 2M RAM 的 NDS 上 g++ -std=c++11 不关 RTTI 和异常只要-Os -s 了完全无压力，就算-O0 -g -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC 都不至于跑不动；映像大小不爽自己一个个调优也不见得会费多大事，大不了魔改一下标准库实现，就差点手撸 softmmu 了……
用不用“高级特性”倒是无所谓，不过 C 的抽象无能也救不了你手贱乱用自己不清楚代价的东西导致的资源浪费。

为什么需要学 C++。是个（你能找到的）语言在“有没有”这方面不都基本差不多？
也就 C 这种得纠结找这类玩意儿吧。

取决于什么叫“好的”。
如果说是满足功能性能需求，那么看要求什么场景，基本上得自己 profiling 。不过作为中间件，不做二次开发，一般不需要太关心是什么语言实现的。
如果是想要“看看”代码学习怎么写，那么 ZeroMQ （的历史版本）的确值得一看——堪称 C++语用在这个领域中最负盛名的反面教材： http://250bpm.com/blog:4 （当然，避免掉坑主要重点不是代码本身）。

细看了下其实和其它角色无关，这个 CTO 常识性视野不够，作为 CTO 都算站错位置了。
根本就不需要看什么全栈嘛……（其实严格意义上真没几个全栈的，不算硬件，能自己往上撸机器码造汇编器的能有几个。）

没有统计不好说，但常理上来讲，因为技能树限制，能当成正好称职的 PM 用的 CTO 比 CTO 难找多了。

看标题就知道扯得上边的只有 trademark 。
……看适用的商标法流氓到什么程度。
就这里的 case ，因为商品或服务项目没有交集，对方要举证构成侵权一般都是很有难度的，你可以十动然拒。
@bugmenein 搞清楚版权和商标权是两回事，谢谢。

@UnisandK 转也留个出处吧……虽然不难找。

倒是巧合，刚在看 dpdk 的代码。

不过这个说到底也是根据场景优化的了。而且大概年代的关系看样子挖掘的还不够，比如提到 cache 也没管 cache allocation 什么的新型黑科技……

@xieyudi1990 做 uncore 的？

@snow9312 还要连线啊……手机能 clipboard 就懒了（虽然显然没电脑方便）。对我来讲输入罕用字符更费劲……

另外电脑上发大段文字我也会另外保存或者至少习惯性复制一遍，省得被网络质量坑了。虽然不能说浏览器的锅，但因为 Web UI 在发送完之后普遍不会保留原来的内容，所以坑比普通桌面程序更常见。

@GeekGao “请尽量让自己的回复能够对别人有帮助”，我想如果能提供一点不那么常被引用到的关键词，大概也算……当然，建立在这里的大部分读者不是 “装睡的人” 以及 “根本醒不来的人” 的假设上。

@psklf 关于这点我想补充，其实也未必就是最终用户不懂需求（尽管不懂 copy paste 的用户绝对数量确实还是有不少），而是普遍不敢足够确定自己的需求应该被实现而使之作为业内惯例。因为非专业用户也基本上都知道大部分用户不是开发者，而开发者需要为这些非开发者用户服务，所以就不太好意思抵制渣解了。我倒是希望这类用户能联合起来给某些不知所谓的巨头实施无产阶级专政，让他们认清现实，看看真正的普遍用户需求是什么，而不是瞎制造本不存在的需求给用户洗脑（嗯，婊的主要就是苹果和 M$还有跟风的）。
大概是经验差距和现有解决方案能够提供鲜明对比的关系，这点 PC 上还是比较方便的，看看 Windows UWP 的下场就知道了（尽管理论上来说 UWP 确实可以做得更先进）。反过来不管是在用户构成还是替代解决方案上，移动端和 Web 本身可能真的已经没救了……人生苦短远离坑货（虽然也不需要做到抠脚皮大汉不用手机那么彻底）。

@psklf 我当然知道不是一回事。然而你没看见我是嘲讽么……
从一般意义上来说，普通用户都是抖 M ，见识有限而对烂解决方案的容忍能力强过头了。所以别指望通过吸引非用户转变成用户来作为主要扩张手段的市场能优化资源配置；不管是开发者还是最终用户，你入“行”得越早，知道得越多，就越有可能是之后大势所趋的牺牲品。
这种劣币驱逐良币的事例历史上有很多，有些还成为了历史包袱，简直时泪……远的比如说 UNIX ，比如说 CISC ，比如说 hierarchy-based security design ，比如说 Java 。
只不过历史上的东西更集中影响开发者和特定专业领域的用户。近来的发展终于能影响非特定领域的最终用户了。 Web 普及以来才开始接触 PC 的用户有多少能说清楚 Web 的缺陷呢？又有多少 Web 开发者花了多少年时间才能对 IE6 和 Flash 说“不”呢？现在的移动端 app 搞不好没几年就会变成 Web ，而且因为封闭性和对个别厂商依赖更强，前途更不好说。
等不碰 PC 移动端的用户足够多，你就会再次享受到被多数用户“需求”绑架牵着鼻子走的滋味了。现在只是另一个套路的开始罢了。

现在好多服务都只有 web 端，没有 pc 客户端， 不开心，我不喜欢在浏览器上打字，更不喜欢在浏览器上填重复的内容 repeat myself 最后还崩溃了，在客户端上直接 copy paste 多开心啊：）

讲道理，有电脑端也并不见得有球用，比如 UWP QQ 连粘贴选中位置都能无视……浏览器也就是比这些的烂环境成熟点而已，而且考虑资源占用 /装插件什么乱七八糟的要求，并不怎么有节操优势。

@shimanooo @mathgl 影响选取哪种 weak ptr 的 ownership 基本上本来就是应该最晚在详细设计时确定清楚的东西，不应该拖到实现的时候临时添乱。如果最后还发现引用环，说明设计有问题。
GC 实际上是把明确责任也延迟了，所以容易玩脱。
至于竞争，还是一点：注意粒度，避免不必要的可修改共享资源。 RC 也没什么特别的，无非就是更强调考虑造成（伪）共享是不是合适而已。设计时避免不了 aliasing 的那就老实 sharing ，实现后发现瓶颈再考虑是不是改用 GC 或者池来优化。

RC 和 tracing GC 都是 1959 年发明的。现在一些 GC 也基于 RC ，但典型 GC 的主要指后者。
想要从大局对比，去掉 A ，谢谢。 ARC 是什么年代的东西了……而且讲真，离“广泛采用”（不是看你用户数，而是看用在多少解决方案里——即便现阶段看用户数也一样）差远了。——然后才发现，文章里讲的似乎就是 RC 而不是 OC/Swift 的那种 ARC 。
（虽然从字面上讲， C++那套才更有资格当成 A 。）

@introom 读 spec 能读到满腹槽点只能长篇大论就差不多了……