今年省内的排名 / 今年省内的考生人数 * 某年省内的考生人数 不就约等于 某年省内的排名，只要录取政策没啥变动，多半就能这样参考了。

以后想考研，本科没学位，硕士也不会给学位，这样多可惜。

为了能在 mac 和 windows 上开发同一个项目，我选择了 vscode + cmake 。由于一些个人喜好，配置起来花了不少时间。

如果学习用的是 windows 系统，Visual Studio 是最友善的了。

@xingshu1990 点外卖时会比较累。健身餐之类我会去了解下。我目的也不是减肥，是想饮食上能更科学点，对自己的身体状态多点信心。特别注重这些，也许是有点心理因素存在。

@iannil 多余的蛋黄怎么办，扔了好浪费。

@iannil 我眼瞎了，没看到绿色蔬菜啥的。

@iannil 考虑到消化系统的“作息时间”，应该得分成 3-4 顿来吃吧。然后像维生素和一些人体所需的微量元素，怎么从食物补充？

@TomatoYuyuko 确实有在考虑代餐
没有厌食症，一天三餐都按时吃。

@hupo0 我靠，我想换行怎么就发出去了。
https://github.com/Iplaylf2/no-stream
主要看顶级目录，package.json 和 gulpfile.js 。

你可以参考别人的库是怎么打 npm 包和发布的，比如说我的。

@cenbiq 看看所谓的 Zero cost abstraction - 刘雨培的文章 - 知乎
https://zhuanlan.zhihu.com/p/24975048
吐槽 C# - 刘雨培的文章 - 知乎
https://zhuanlan.zhihu.com/p/30653282

参考这两篇回答，17 年的 C#还没有对 linq 进行优化。虽然用迭代器也是相当于只遍历一遍，但是迭代器“调用”迭代器的过程还是会有额外的性能损耗。完美一点的是，能做到跟 C++一样，把迭代器 yield 的逻辑内联到一个循环里。

想来 no-stream 的做法，是函数调用层面，把"yield"部分通过函数包函数的方式合并到一个循环里。虽然也是有函数调用方面的开销，但目前来看，会比 JS 的 Generator 还节省性能些。

从现有的 C++和 Rust 的案例来看，其实正道还是 iterator，似乎这样的结构更容易优化。linq 也是在正道上，只是需要引擎对这部分进行优化。与之对应的是 JS 的 Generator 。可惜就是目前他们还很拉胯。

@musi 所以用了似乎，实际上，如果要提高代码的表达，很多时候不会选择把逻辑都挤在一个循环里，至少我是这样的。

@geelaw 比较的代码确实有的斟酌的地方，但是太难找到合适的，就粗暴点只比较了 map 和 reduce 一起用的情况。

就是不想好好写 for 循环。

@shyangs lodash 没用过，我才知道 chain 。看了下源码，他用一个 Wrapper 的抽象，在求值前，把中间的 actions 合成一个。虽然感觉大家想做的事情一样，但实现上效率不那么高。不过 lodash 自带的东西多，容错好，本身不用太注重效率。

实际 benchmark 跑下来，速度和数组自带的方法差不多，但是内存上应该会更优越。

@Jirajine iterator 转成另一个 iterator，一般是包多一层，该做的“结束检查”还是不会漏的，还是会有额外的性能损耗。实际用 benchmark 测也会发现比较慢。

@cyberpoint 表达到位

@eason1874 应该不叫循环展开，是把多次循环合成一个。只见过 c++ 和 rust 有这类优化，而且对代码有不少限制，可能高级语言要考虑闭包什么的。

这种框架类的东西，能火起来得靠运气。

我之前在知乎也看过楼主的几次发言，点开过 github 好几次，就看了个新鲜。正如你不喜欢 JSX，我也不喜欢 DSL，模板语法让人没有仔细看的欲望。

但这不是问题，仅仅是 ef.js 运气不好，react 当初的 jsx 我也喷过，为了生计沉下心去用，越用越香。

让我从头写个网站，特别是打工的时候，框架只会从 vue, angular, react 里选一个。谁让 ef.js 没火呢？视图的代码和框架耦合很深，又是前端代码比重最大的部分，如果使用过程遇到什么坑，换一个框架几乎等于重写，谁愿意冒这个风险？