@cooioobb
我前面说“‘相对的价值’不存在一个公认的算法”，是因为同样的东西，对不同的人，实际价值是不一样的。
比如我不打算生孩子，那么学区房的溢价对我就一文不值。
但是大多数买房的人要考虑教育问题，所以学区房在市场上就可以卖出高溢价。也就是最后的价格由市场决定（不是由成本决定，更不是由抱怨决定）。

租房的时候也存在同样的问题，比如企业聚集地周围的房子会偏贵一点，因为有许多人看重“上班近”这一属性支撑起了价格。
但是一个不在意上班近的租客，发现这房子除了上班近之外也没啥别的好处，那么就可能不会租这个房子，转而选择 同价格更远面积更大的房子 或 更远价格更低其他都相似 的房子。
这都不碍着上班近的房子可以租出更高的价格并且还有人租。

@yimity
“getElementBy 获取到的是动态的，即 你增加了 dom,再获取还是可以获取到你最新增加的的，你删掉了 dom，再获取的时候，之前获取到的就不在了，就是每次都是实时从 dom 树里面获取。
而 querySelector 是引用，即获取一次后面增加的 dom，不会获取到了，删掉了 dom， 在代码中还是能够用(但是会报错)。”

求依据：标准，源码，或示例
你说的可能是 getElementByClassName/TagName 和 querySelectorAll
楼主这个好像没这个区别

@qinxi 本来想写 19260817，感觉太离谱了点
不过不是不可能哦

@cooioobb 6k 的房子装修一定就比 3k 的好么？
另外“相对的价值”不存在一个公认的算法。

这帖子逻辑是有问题的 ...
资产价格最终由市场决定，没有一个“合理”的价格。楼主说现在一套月净赚 1300，从市场的角度是合理的，如果市场发生变化，一套月净赚 2510 或者净赚 251 甚至净亏都是合理的。所以不存在“真实租金”太“便宜”或者太“贵”一说。
房东会寻求利益最大化（尽量涨租金），而给平均租金设限的是平均工资，就算租客不要求这些东西，最后租金还是不会比现在低多少。
“盖房不用钱”——错，楼主一套房月净赚 1300。还是说楼主想一年回本三年血赚？

考虑这样一个问题：同一座城市（物价、人工成本接近），有月租 3k 的房，有月租 6k 的房，难道说月租 6k 的房每个月贵的 3k 都是用在租客“额外要求”的东西上？

@grewer 不能拿 GitHub 做例子，据我观察 GitHub 是最激进的站点之一，我 Mac 上的老版 Chrome，GitHub 不能加载最新 commit，branch 的菜单点不开。另外 YouTube 不能看。

其他网站没出过问题，说明 GitHub 和 Google 可能确实对浏览器要求比较高。

没有

#8 难道是楼主的小号 ...

用 querySelector + 字符串拼接意味着可以 query 的不只 id ... 在输入的字符串后面可以加其他选择器

@ysc3839 选择器只用解析一遍，有缓存
但是用来做同样的工作，前者是要稍微慢一点（因为确实包了一层）

改变世界有两种，第一种是让世界变得更好，第二种是让世界变得更差

90 后暂时叫四分之一人生危机比较合适一点

我想问楼主是怎么找到这个节点的 ...

楼主整一台之前应该先虚拟机 /黑苹果试试

真正区别在于一个良性的彩蛋是不会自己触发的 ...
以前的“彩蛋”都是需要一番骚操作（用户绝大多数情况下不会触发）才能整出来的

antd 倒好，直接送人头
在那个时代这种到点触发的恶意程序被归类为病毒

@wheeler

在主流编译器 + 主流硬件的实现中不会，编译器会写死识别一些常用函数，比如你写个 sin 可能就没了，但是一般不会认 sleep 函数。
但是注意这个 thread_01 并没有做任何同步，按标准来的话是 UB。
volatile 这里没用，可以加锁，不过一般是用 atomic

另外楼主可以去看下 Futamura Projection …… 更绕，但是 Java 几年前靠这个实现了自举

Rust 编译器最开始是 OCaml 写的——得到”OCaml 写的 Rust 编译器“，为简洁我们把这个编译器称为 P
注意 P 不需要做的非常完善，也不需要实现所有计划中的语言特性，只要能编译一些基本的程序就行，我们把 P 所实现的”原始版本的 Rust 语言”称为 R0

等 P 做到能用的程度，就用 R0 来写 R0 自己的编译器，我们把这个编译器的源码称为 S0，S0 可以直接使用 P 编译得到 E’（注意这里我们把源码和编译器分开了）

由于 E’ 也实现了 R0 语言，因此可以用 E’ 编译 S0，得到 E0

这时我们说 R0 实现了自举。
注意虽然一般默认 OCaml 是 AOT 编译的，但是 OCaml 也可以解释执行，P 也可以使用 JavaScript 等纯解释的语言实现，虽然 JavaScript 是比 Rust 更高层的语言，但是 P 仅用于实现 bootstrap，具体用什么语言实现不重要

在得到 E0 之后，P 就可以不要了，之后的开发全部在 S0 上进行（你现在去 Rust 的 GitHub 翻历史还能找到早期的 OCaml 编译器，不过在 bootstrap 之后早就被删了），之后编译器的第 n 个迭代版本的源码和可执行文件我们称为 Sn/En

注意此时 R0 依然是一个原始版本的语言，在完善语言设计和编译器实现的过程中会加入新特性或做出破坏兼容性的修改，而编译器的代码 Sn 本身可能也会使用到新特性，这时必须保证 E(n-1) 能够编译 Sn，也就是你不能一边实现新特性，一边在新特性的实现代码中使用新特性

@wevsty 楼主这个明显是个 minimal example，在实际代码里面很多不是”函数中没有做除了++以外的操作“的情况（比如在算法中更新全局的 statistics （嘛，虽然这种情况一般应该用一个 local 变量存下））
如果这个变量的 live range 比较长（在函数中被用了多次），并且没有 function call （或没有 function call 作为 sequence point 的保证），那编译器是可能选择把它在寄存器里面扣一会的

volatile 是给编译器看的，过了编译器就不需要了。也就是如果楼主直接写汇编是根本不需要 volatile 之类的概念的。
这是条件之一。也是楼主提到的

另一个条件是 SO 回复中的"function call (a sequence point in C)"（ C++ 里面是 sequenced-before 关系）
，这使得编译器必须保证生成 #3 的代码，而不是先放到寄存器里面等 unlock 之后再存回内存

如果没有这个保证，书里面的问题是真实存在的，楼主不能只看 OS 不看编译器

解决问题有 top-down 和 bottom-up 两种方式，你说"理解"，你是想要 top-down 的理解，还是要 bottom-up 的理解？

从完全 bottom-up 的角度，这些东西都可以理解为“一切最后都变成 callback”，这种过度的 Reductionism 对真正理解问题无益，同样的现象发生于“一切编程语言的‘本质’都是汇编”和 #6 的“一切语法都是语法糖”等言论上。
从完全 top-down 的角度，则可以说“一切都是异步”，这同样对理解问题无益（至少没有突出各项之间的区别）。
我见过很多人在看问题时过度强调其中一方面而忽视另一方面，导致“理解”出现障碍。尤其是遇到新东西的时候。

楼主说的“Promise 本质上还是 callback 机制”这就是从 bottom-up （实现）的角度看问题，并且将其单方面地作为”本质“，比较中立的说法是：”“Promise 主要利用 callback 机制实现“。

从 bottom-up 的角度，V8 的 native implementation 确实是使用的 generator 封装 async/await （其他 JS 引擎应该也差不多）；而从 top-down 的角度，使用者无需关心 async/await 是如何实现的（但是我猜标准可能就把 generator 和 async/await 两者绑到一块了）。