In [4]: N = 10**8

In [5]: arr = np.random.randint(0, N, size=N)

In [6]: len(arr)
Out[6]: 100000000

In [7]: %timeit set(arr)
36 s ± 122 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

给你一个时间作参考。。。

我记得 SQLAlchemy 可以把 SQL 结果提取出来变成 object。

另外我大概理解楼主为什么要写不合法代码的理由了，是想研究 C++ 返回值地址的问题嘛？

但是 C++ 编译器会根据返回值的赋值进行代码优化的。

比如：

class A { ... };

A someFunction() { A a; return a; }

A target = someFunction();

在深度优化的时候不会发生拷贝，直接在返回值 target 上调用构造函数。

@amiwrong123 不合法的理由，见 5L 和 11L 的疑惑。

首先，楼主你两段代码都是不合法的。

对于不合法的代码，C++ 编译器没有义务给你吐出合理的结果。

@soho176 我现在觉着这还是有点道理的。道理不是什么阴阳五行这类的东西，而是因为我们三餐是定时的。根据三餐的时间反推，一定有一段最佳睡眠时间。其他任何时间睡，哪怕时间够了，效果也不好。
----

这是来自最近一年亲身实验后的结论。

标准 Markdown 和目前我见过的各种扩展 Markdown 没有这个功能。

而且说实话，你这个需求 LaTeX 都不好处理，或者说一般人不这么处理。我见过的文献，如果是同一本书不同的页号，大致上的格式是这样的：

Some sentence (author date; page xx-xx); another sentence (author date; page xx-xx)

References

(author date) "book title" ....

就是说引文还是只有一遍这本书，但是在引用的时候标注出来也好。

@wumao 从原理的角度（即 JS 引擎的实现的角度）来看，字符串不是简单数据类型。不要从语法层面去看问题。

别的系统也会很慢。

这是文件系统的固有性质。

@qile1 不知道，我不用记事本或者 nd+。会不会是 BOM 问题？

我一般用 Visual Studio Code 或者 PyCharm。

对于我自己的项目，如果文件内部有非 ASCII 字符，我会加上。

退一步考虑，就算 Python 3 解释器不关心它，有些编辑器或者 IDE 说不定也会关心它。

加了又不会怀孕 😒

楼主可能没用过超薄本…… 你就算老一点的那种厚厚黑黑的 Thinkpad，75 度也不算什么。

Squid 大概行，但是我没配置过。

@passerbytiny 呃，想了想也说不定。说不定哪天 JVM 的 JIT 特别牛逼，处理 Lambda 就和 inline 性能没区别了，那 Optional 就能用了。

至于 Optional.get() 抛不抛异常，别用它不就行了（当然这一点看上去没戏，Java 库的历史包袱太重）。还有序列化，当然 Optional 字段不存在就不输出啊。

@passerbytiny 所以我说了嘛，如果要超级好用的 Optional （包括解决性能问题），得要别的语言，反正不能是 Java。

@kuyuzhiqi 至于 Optional<T>，可以设计为内置功能而不是打补丁打上去的类。这样的话也不会有多少效率损失，字节码层面完全可以进行编译期优化。当然这就变成另一个语言而不是 Java 了。

如果是 Java 的话，那就只能靠约定了。虽然我觉得 Optional<T> 的约定很舒服，可是也并不是所有人都认同这种用法，就没办法了。

@kuyuzhiqi 不不不，引用 /指针其实没问题，但是可以设计为，不能把 null 赋予一个引用 /指针。即，一个引用 /指针的初始化必须是有东西的。如果你想表示一个可能是空的东西，就用范型叠加，比如 Optional<T>。

当然，Java 的范型是补丁打上去的，是个 shit，这是另一回事情了。

@kuyuzhiqi 你这个原则是建立在 Java 作为强类型语言却有 Null，而且因为早期没有 Optional，所以大量开发人员不保证不传回 Null 这一事实基础上的。

如果随处要检查 null，会带来巨大的开销。现代 CPU 都有流水线，一个 if 条件判断会打断流水线，造成几十倍的性能损失。虽然 Java 有牛逼的 JIT，对于大部分情况下不返回 null 的接口，很多时候可以弥补这一性能损失，但是如果一开始就不需要判断 if，岂不美哉？