我终于觉悟了！原来我看了半天常量，其实我在调试的部分根本不在 System.Math 类里！
它是一个已经准备好进行终止的程序！

(import "env" "_emscripten_asm_const_i" (func $import24 (param i32) (result i32)))
(import "env" "_abort" (func $import0))

get_local $var3
if
i32.const 0
call $import24
drop
get_local $var2
get_local $var2
call $func221
call $func713
drop
call $import0

弄了半天其实是说

if (arg4)
_ = _emscripten_asm_const_i(0)

_ = func713(func221(45966456), 45966456)
abort()
!!!
我的方向都错了！

$func762 是个递归函数，叠了好多层了

然后我换了一个策略，不搜索魔数了，搜索方法签名都打上断点

(param $var0 f64) (param $var1 f64) (result f64)

https://github.com/migueldeicaza/mono-wasm-mono/blob/8eb6ac3a88b9e6ca5127dce5a3d3c075bf1586a4/mcs/class/referencesource/mscorlib/system/math.cs#L86

(param $var0 f64) (param $var1 i32) 签名部分是

你们这样暴力尝试是不行的！批判一番，下次不要再白费功夫！ 🐸

三个小时打水漂的惨痛教训

#huawei #China #Low 质疑：你还要注册什么商标，自从某事件后你说了那么多，可华为这么多年了，所谓一直自己后面有支持，为什么连一个自己的 ISA 架构标准都没有？华为海思主要还是半导体和无线通讯公司，对所谓的（高端）芯片（微处理器）的研究还是不完全自主的，对真正完全断供如果只有能力啃老本也只能苟且一两年可能就会被市场甩掉？为什么你说什么“鸿蒙”操作系统，可是却不告诉用户有些诸如平台生态的问题你们会怎么解决？为什么你们的“方舟”开发平台介绍有误导开发者的嫌疑？为什么对 Android 图形架构的优化也被混在这个“编译器”里面了？为什么现在才开始研究编译器一类的东西？为什么『IO/计算密集分析』这种实现起来完全可能没有多少复杂性的优化算法都会被拿来当成大成果公布？为什么以上提到的“鸿蒙”“方舟”“优化”现在还没点面向工程界公开动态？

听说华为注册了“玄武”的商标。如果最终能注册下来就很有趣了。

因为我们也注册过，当时商标局的反馈是：这是宗教相关词汇，不允许注册。 ​​​​

——tombkeeper

#China 不过中国的确是不太缺人，我就知道现在肯定有十几个能干这类事情的大佬，可是不知道华为里有几个[^2]

平均质量技术水平不够怎么办？人口拿来凑！人口基数在那里啊，何况中国又不缺高等教育。

其中有一个大佬自己研究了一两年的 GCC（知名自由软件跨目标平台跨语言优化编译系统）写了一本，还为国产的 PAAG[^1] 并行阵列处理架构（西安邮电大学自主设计的，并且绝对可以自主设计）进行了 GCC 的移植[2]

其中有一个大佬（嵌入式 PLD 设计的，比方说开发门禁系统、数码相机都需要这类人才）在华为海思工作过，参与了跳频 OFDM[4]（正交频分多址）无线通讯系统（4G 世代）的设计
可是那个大佬不是专门做所谓“芯片”（微处理器）方面的人才，不过现在创建了明德扬教育可以去看看

—
[^1] PAAG: polymorphic array architecture for graphics and image processing. 见 [1]
[^2] 华为里也有一些（参考这篇论文[3]，卖五毛...），不过技术水平在那一群里也比较平凡

[1] 李涛,肖灵芝.面向图形和图像处理的轻核阵列机结构[J].西安邮电学院学报,2012,17(03):41-47.
[2] 张薇薇,王亚刚.基于PAAG系统的编译器移植技术设计与实现[J].计算机工程与设计,2015,36(03):664-668.
[3] 宋奇.运行速度大突破 华为《方舟编译器》详解[J].计算机与网络,2019,45(09):32.
2019年4月11日,华为春季发布会上,除了P30系列,另外一个词也在程序员届火了一把——"华为方舟编译器"。据介绍,华为《方舟编译器》可以让安卓性能突飞猛进。近日,华为王成录博士对《方舟编译器》的原理进行了讲解,表示华为从2009年就创建编译组,期间推出自研编译器HCC、编程语言CM等,一直到如今推出了《方舟编译器》。什么是编译器编译器是连接人类世界与机器世界之间的一座桥梁, ⋯

^我就不吐槽上面那个错字了，还有 HCC 听起来像 C 编译器吧[^3]，编译器依据使用的技术、实现的源语言抽象程度范式和版本，实现难度有区别并且也是分好坏的，一门不知什么范式、有啥语法结构特性的 CM 语言，一个不知道多高水平的 C 编译器能证明什么？现在中国学编译原理的学生，随手抓一个都能写 C 编译器出来，但是编程风格还行、会函数式编程、完全理解静态分析程序变换的精英又有多少？C 编译器是“PL/0”级别都可能弄的，只会这一个不能说是能上实际工业的工程师，更不配当华为“编译组”的技术标准，自己都吹是 10 年经验了，那怎么不弄个 Go 或者 Rust 出来？何况一个方舟吹上天，实际上背后 EMUI 做的视图渲染缓存优化还出力不少，然后对外宣称是编译器这种“高大上”玩意和 GPU Turbo 都有的大功劳，听起来这像是中国第一电子通讯企业的作风？
[4] 曾菊玲,金力军.OFDM跳频通信系统设计[J].移动通信,2004(S2):155-158.
[^3] 但是 GCC 是 GNU Compiler Collection，然后 HCC 这个关键词在知网 cnki.net 上找不到任何发表的论文，这能拿来吹，真的很服气，就是“内部”也应该发点文章出来吧？

说起来看这些引文西安邮电大学和中国科学技术大学真的是人才辈出

#DB 同意。如果王垠真的是那么说的，那么我觉得他错了，他的理解太偏向结构化编程范式了，无视了数据库的确只是为应用提供数据持久化、查询等操作的服务，不是什么结构体(C Struct)、数据项目实例和一大堆函数接口，那就把数据库当成 GC 堆了。

“就是C的struct， 就是指针, 为什么不能RPC” 这句话... 不是很容易理解，我的理解是：为什么关系型数据库的『记录』上的操作不能直接被拿来当成远端过程调用去实现而非得 SQL，那显然就混淆了操作界面（接口）和实现，在面向侧面编程（AOP）甚至模块化里这是大忌，管你的理论学的再好，也永远有你没有学到的理论。

数据库系统也是信息技术应用的重要组成部分，虽然学 PLT （程序设计语言理论）的人一般看什么都会开明一些，但有时候还真是会有些许误解。

王垠开篇便开始详尽叙述数据结构和数据库的相同之处，如何“一个表本质上是一个数组”等等。

... 这不用我说肯定是不对的吧？关系表的本质并不是数组，而是抽象『元组』的集合

可以说，“只告诉它 What，而不是告诉它 How”，只是一个不切实际的妄想，而且它并不是 SQL 首创的想法

怎么可能呢？有的时候书上的东西也只是误会了而已，比如说所谓的 4GL（第四代计算机语言），其实这个概念根本不应该存在，
因为自存储程序型计算机开始，我们只是一直在提升抽象层次而已，从机器代码到它的助记符汇编（这里注意汇编不是一个特指，比如它不一定得是 x86 汇编），
到 Fortran, Basic, C, C++, 、上面的 Lua, Java, Python, Haskell、Agda, Coq, Prolog 什么的，甚至各种 DSL，甚至可以说 TensorFlow, PyTorch, Theano 都是编程语言，因为他们是描述计算的方式，而计算和描述方式可以有很多种，这怎么可能是空想呢？它当然不是 SQL 首创，因为 1920 年组合子逻辑（被证明和 Lambda 演算等价）就已经是一个例子了。这是 PLT 领域一直在变为现实的事情。
回答者对这个的观点我举双手赞成。

Prolog （miniKanren）的性能问题在 SQL 里面得到了部分的缓解，这是因为 SQL 对于基本的数据结构进行了“索引”

作者只回答了后半句，我对逻辑那边的东西也不是多熟悉，毕竟我工程得先过了再说。
然后这个索引我也不知道是怎么回事... 大概就是 SQL PRIMRY KEY 吧，考虑一下 hash table，我们可以通过先利用 int hashcode 的方式进行第一次剪枝排除，有冲突才需要 O(n) 再线性或者二分（如果冲突表是 Ordered, 有序的）查找

然而 SQL 的表达力也受到比 Prolog 更大的限制。很多 Prolog 可以表达的问题，SQL 没法表示。所以后来你就发现，SQL 其实只能用于非常简单的，适合会计等人员使用的查询操作。一旦遇到程序员需要的，稍微复杂一点的数据结构，它就会引起诸多的性能问题。

那 Agda 可以表达的类型问题

data forall {i l} {l : Nat} (a : Type i) Vec a l : Type i where
  nil : Vec a

0
_cat_ : a -> Vec a l' -> Vec a (suc l'')

啊写的好难看，而且我这里没有 Agda，那就照抄原文算了

data Vec {i} (A : Type i): Nat -> Type i where
  [] : Vec A 0
  _cat_ : forall {n} -> A -> Vec A n -> Vec A (S n)

那 Haskell 的 fold operator 和一些应用

foldr :: (a -> b -> b) -> b -> (a -> b)
foldr f v [] = v
foldr f v (x:xs) = f x (foldr f v xs)

递归的基线条件是 arg2 为 nil []；每层递归等待直到基线条件，回溯时第二个分支的最后一层先被 (f x v) :: b 调用，之前的结果被归纳直到彻底完成。

应用比如

product xs = foldr (*) 1 xs
sum = (foldr (+) 0) :: [Int] -> Int
filter p xs = foldr (\x rec -> if p x then x:xs else xs) [] xs


dropWhile p [] = []
dropWhile p (x:xs) = if p x then dropWhile p xs else x:xs

dropWhile' p xs = let (res, _) = foldr (\x (rec, sav) -> (if p x then rec else x:sav, x:sav)) ([], []) xs in res

这个就不那么 trivial 一点，然后我自己也想了很久，从这里扒的。

那就简单说，(\x -> lessThan 2 x) 这个

dropWhile' (<2) [9,0,1,2,3,4]

实际上递归
4 -> ([4], [4])
3 -> ([3, 4], [3, 4]) 👆 (cons sav, cons)
2 -> ([2, 3, 4], [2, 3, 4]) 👆 (cons sav, cons)
1 -> ([2, 3, 4], [1, 2, 3, 4]) 👆 (id, cons)
0 -> ([2, 3, 4], [0, 1, 2, 3, 4]) 👆 (id, cons)
9 -> ([9, 0, 1, 2, 3, 4], [0, 1, 2, 3, 4]) 👆 (cons sav, cons)
... -> （依此类推）

是不是我 SQL 不能表达就是我贫瘠 🌚???

更要命的是，这种性能问题的来源是根本性的，不可解决的，而不只是因为某些数据库的 SQL 编译器不够“智能”。很多人不理解这一点，总是辩论说“我们为何需要 Java 而不是写汇编，也就是我们为何需要 SQL。”然而，把 Java 编译成高效的汇编，和把 SQL 编译成高效的汇编，是两种本质上不同的问题。前者可以比较容易的解决，而后者是不可能的（除了非常个别的情况）。

首先：SQL 不一定需要编译器，它只需要实现查询操作并且给出结果就可以了。

“我们为何需要 Java 而不是写汇编，也就是我们为何需要 SQL。”

然而这个言论明显就是正常的，因为它把 SQL 当成了好用的工具，而 SQL 本身作为工具就很好用。
当然 SQL 也不一定得编译成汇编，其次，这里用“机器代码”更为合适吧，再其次，『为了自己能开心地去游乐园玩一趟而费重金弄一架私人飞机』这种事也不太实际吧，为什么我非得为实现查询语义来刻意去编译 SQL 本身？即使 SQL 可以根据数据库管理系统的信息被翻译成等价的查询程序？

我只举一个例子来说明这个问题。如果你需要迅速地在地图上找到一个点附近的城市，SQL 无法自动在平面点集上建造像 KD-tree 那样的数据结构。这是很显然的，因为 SQL 根本就不知道你的数据所表示的是平面上的点集，也不理解平面几何的公理和定理。跟 B-tree 类似，知道什么时候需要这种特殊的索引结构，需要非常多的潜在数学知识（比如高等平面几何），所以你肯定需要手动的建立这种数据结构

这是当然的啊，你不告诉 GHC dropWhile 的定义，只给类型人家自然也没办法弄出个你要的实现出来，数据可能有很多种，人家怎么能通过有限的数据和计算能力猜测你想要什么。

type Point2D = (Float, Float)

那即便不使用 kD-Tree 算法也是可以简单判断 filter 一下 floating point range 就可以得到 Rect 范围内的城市了... 但是要再优化为什么不写 C 扩展？这是它的错吗？

你发现了吗，你其实已经失去了所谓的“描述性”语言带来的好处

没有啊，而且你说的(描述性语言⇔逻辑式语言)
从某种意义上 SQL 还真的可以算是“逻辑式”，不过是 1 级的逻辑式（它不能组合操作成非线性
而且很多人并不认为它是逻辑式语言，只是觉得它是 "4GL" 而已

这就是为什么你几乎总是需要手动指定索引的原因，而且这种索引需要数据库“内部支持”。你一次又一次的希望 SQL 能够自动为你生成高效的索引和算法，却一次又一次的失望，也就是这个原因。当然，你永远可以使用所谓的 stored procedure 来扩展你的数据库，然而这就像是我的 IU 同学们用 miniKanren 来实现 HM 类型系统的方式——他们总是先使用一种过程式语言（Scheme）来添加这种描述性语言的“相关特性”，然后欢呼：“哇，miniKanren 解决了这个问题！”而其实呢，还不如直接使用过程式语言来得直接和容易。

首先“过程式语言（Scheme）” 我记得你自己之前好像喷过部分 Haskell 民『Scheme 不是函数式』言论的，显然 R6RS、Racket 这类 Scheme 都可以使用过程式的方法编程，但一般都认为它们更像函数式
然后你说的描述性语言是指使用 Hindley-Milner polymorphic type system 的 Haskell 吗？可 Haskell 真的不是逻辑式吧...
后半句的逻辑完全是冲突的，而且 miniKanren 这种类似自动定理证明器的东西（虽然我不了解）明显会比纯过程式编写类型检查器推导器上会强很多（比如，它就可以描述某个未知量 t 的类型符合 HM 的类型约束，而不是手写检查算法过程），因为它长得和形式化逻辑系统很像。

而其实，数据结构的理论，可以很容易的解释所有关系式数据库里面的操作

肯定的啊，因为都是现代的计算机来执行，数据结构肯定比关系型数据库要广。

每一个“foreign key”，其实就是一个指针

差不多，但回答者也给了个补充：更接近于一个”reference“，而不是 C 的 Pointer
何况还有 ON DELETE CASCADE 呢，它就更像是完整的对象引用了

在实现上，join跟指针引用有一定差别，因为 join需要查“索引”（index），所以它比指针引用要慢。

JOIN 只是指明了抽象语义！（划重点）
即便你说是在实现上，你讨论的也太泛泛了

所谓的查询（query），本质上就是函数式语言里面的filter, map等操作。只不过关系式代数更加笨拙，组合能力很弱。

这就是 SQL 的需求，若是单单这些『组合能力』能一手遮天，那为啥没人用 Python 写 SQL 解释器？为了性能和现实世界不可避免的东西抛弃『组合性』『重用』的例子比比皆是，比如现在的人工神经网络组成粒度问题，（如果用 OOP 方法设计）肯定没有人会“灵活”到每个神经元一个对象吧。

[sin(1/x) for x in xs if x > 0]


[sin (1/x) | x <- xs, x > 0]
  where xs = [-100..200]

这 Python, Haskell 的 List comprehension 算不算组合能力弱，可偏偏还是有人用

由于“行”只能有固定的宽度，所以导致了你没法在里面放进任何“变长”的对象

这就不对了，比如 Lua 吧，你是不是可以说，因为 Lua 的 union Value （它是 CommonHeader(struct GCObject) 和 ByCopy objects 的 Product type，具名融合结构体，或者叫结构体）只有固定的长度 size_t
就不能利用 Typed value struct TValue 来依照 tag 解释它的值是『指针』呢，还是 fixed size 呢？
就像 Rust 里也有 DSTs，Dynamic sized types 的支持一样，就是使用 slice fat pointer 实现的，为什么刚才说数据结构可以解释 Rel DB，现在又说 DB 是『青出于蓝而菜于蓝』

比如，如果你有一个数组，那你是不能把它放在一个行里的。

即便是数组，甚至 BitMap 也是可以的，没有听说过『指针』（刚才还提到）吗？

你需要把数组拿出来，旋转90度，做成另一个表B。从原来的表A，用一个“foreign key”指向B。这样在表B的每一行，这个key都要被重复一次，产生大量冗余。

这里“旋转九十度”其实是说给它的每个 Key 命同一个名字（用来表示这是一个数组 a 里的值）
然后每次去做 SELECT * FROM B WHERE id=?; （这里 id 是一个『数组』的名字，B 其实可以是一堆数组所有项目组成的表） 这样的操作？
这一点已经是神仙打架了，看不懂原回复，我只负责辅助理解观点。

使用基本的数据结构，其实可以完全的表示关系模型以及被它所“超越”的那些数据模型

废话。

数据模型可以完全被普通的数据结构所表示，然而它们却不可能表达数据结构带有的所有信息

有区别吗？听起来和 ORM 的思想背道而驰，正好 OOP 就是 SP 的数据、操作的融合加上多态。

最早试图冲破关系模型和SQL限制的一种技术，叫做“列模式数据库”（column-based database），比如Vertica, HBase等。

这里复制原回复
Vertica是使用SQL的RDBMS。Column-Store诞生是为了更有效地解决大数据分析的问题（OLAP workloads），节省硬盘I/O（就是所谓列压缩），运用SIMD等等。不知道这和逃脱SQL有什么关系。

很显然，每一个数组需要一个字段来表示它的长度N，剩下的空间用来依次保存每一个元素，这样你只需要一个key就可以找到数组里所有的元素，而不需要把key重复N遍。

c++11 的 std::string 就是类似的实现

Key 的问题的确是关系数据模型的一个问题，因为它（ORM）的确是强行要求关系，然后利用关系查询哪怕是本来可以直接 select where 的，比如，你想“破格”为一些本质上是双向关系（a ~>(type) b）的数据建模，那就得把一个 nosense 的 ID Key 重复 N 遍，非常无聊。

上面的特性称为 random access，随机访问，意味给地址就可以读写数据，不过这里它是在描述一种关系表格

arys:
key | n | seq
'foods' | 3 | ['apple', 'pineapple', 'pen']
'discs' | 2 | ['江南皮革厂倒闭了', '只因你太美']

SELECT n, seq FROM arys WHERE key='foods';

rather than

key | obj
'foods' | 'apple'
'foods' | 'pineapple'
'foods' | 'pen'
'discs' | '江南皮革厂倒闭了'
'discs' | '只因你太美'

SELECT COUNT(obj), obj FROM arys WHERE key='foods';

不要在实际工程中使用这种结构，它是错误的（不一定保证顺序，而且低性能且不符合实际用途）

我这个菜鸡最开始弄 GeekApk 的一些双向关系，比如 user <~(star)~> app 的时候就遇到过。实际上，这不止是 GeekApk 尝试的问题，所有要求动态双边关系的应用程序都得想办法解决，解决方法往往是：把关系也认为是『有地址（id）』的实体(entity)...

CREATE TABLE users(id INT PRIMARY KEY, name Char NOT NULL, nick VarChar);
CREATE TABLE apps(id INT PRIMARY KEY, package Char NOT NULL, name VarChar);

CREATE TABLE relation_user_app_star(id INT PRIMRAY KEY, user INT references users(id), app INT references apps(id));

对这个回答者的回复也有点奇怪
这是什么压缩算法？把字典压缩理解错了？把run-length压缩理解错了？这怎么解决变长问题?
我不知道这和压缩算法有啥关系... 明显只是打算存的数据本身长度缩短了，不过最后一句是对的，照王垠的说法，没法解决变长问题。

其实数据库的问题哪有那么困难，它其实跟“远过程调用”（RPC）没什么两样

又是以偏概全，其实编译原理的问题哪里有那么困难，它和 kotlinc File.kt 有啥不一样？
其实软件逆向工程哪里有什么困难，我 jad ComplexClass.class 就完成了
其实垃圾回收的问题哪里有那么困难，它和“系统自带”的『堆』分配器 malloc() 明明没区别
其实 malloc() 的问题哪里有那么复杂，mmap() 就好了

觉得一个东西很简单甚至等同另一件东西分两种情况：
第一种是你刚入门，对自己似是其非的发现欣喜若狂；第二种是你已经看破人事，游刃有余。
把使用和实现混为一谈的属于第一种情况。

只要你有一个程序语言，你就可以发送这语言的代码，到一个“数据服务器”。服务器接受并执行这代码，对数据进行索引，查询和重构，最后返回结果给客户端

欸，这不就是我开始打算给 GeekApk 加的 Query Combinating Language 吗（Telegram）？看来真是略同、略同（抱拳）。

((<< filter flatten) (# (u) (eq? (user/name u) "duangsuse"))
  (map user-followers
    (user-followers "duangsuse")))

类似 Kotlin 的伪代码
User("duangsuse").followers.map(User::followers).flatten().filter { it.id == "duangsuse" }

虽然比 SQL JOIN 要优秀，但是明显还是不如图数据库直接 bfs（广度优先搜索可达指定类型目标集合 efficient

不过这次原回答者的回复也不太对，恭喜您发明了Spark。但是这怎么解决写入的问题？

控制权，对上传代码的解释权还是在我们这里啊！我们可以不接受可能不停机的程序、我们可以在程序运行过久的时候强行终止、我们可以只提供有限的基本操作使得没有人可以进行不安全的操作来破坏安全需求，只不过这可能不是特别 efficient 而已

如果你看清了SQL的实质，就会发现这样的“过程式设计”，其实并不会损失SQL的“描述”能力

问题是不看情况打破数据和关系抽象，然后用一个简单粗暴不一定健壮（robuest）的逻辑直接替换掉，是不是有点暴力 🐸 了呢？

总结：

现在但凡是写个需要存储的程序基本上都要某种数据库，而且极大概率是“关系型数据库“。如果真如王垠所说，SQL和关系型数据库如此的不堪，就等价于承认所有SQL/关系型数据库的使用者都是傻X。为什么在关系型数据库从学术到商用长达几十年的历史上没有一个人比王垠更聪明，发现这个问题，并去解决它？虽然理论上的确有这个可能性，但是从直觉上看，这种情况发生的概率又有多少呢？

作者：大宽宽[ref]

我也想引用本频道发过的一段话：

所以有时候，看到『存在即合理』这句话，不要忘记它还有一个深层含义：
如果你一看到某件东西就觉得它很莫名其妙，很弱智，那就不要立刻去喷它，因为*存在即合理*。
如果你依然坚持自己的看法，为什么不思考一下，每天有无数人和你持一样的想法，为什么没有人做出点什么证明它真的没有道理？
是因为它后台很硬，还是看不到它合理性的你们 — 都太菜了？


但是，虽然这里批判了王垠的这篇文章，不代表他的所有文章都该差评，
虽然王垠对某些问题的理解还有点偏差，以及“非工”，擅长理论但工程起来基本菜
但是王垠的技术是很不错的。这一点毋庸置疑。
这篇文章是他 4 年前写的，这几年应该还有长进吧，不知道现在怎么样。

说起来某些工程师吹王垠吹够了没有... CS 方向优秀的大牛不少，只看王垠一个，可惜了。

不要看见乌王垠的部分偏差观点被批评就立刻倒戈批判一番 🐸
至少人家还能同时说出数据结构算法和 PLT 俩领域很多名词，也是很多人一辈子都不能达到的水平了

#这周份的dunangsuse 关键字： Python机器学习 Java 数学 电子
Kotlin KotlinNative 奇怪的问题 WASM CSharp
编译器 逆向工程 字节码 数据结构和算法
QuickHack工程 JavaEE OOP
观点明确
中国 华为
理论：新了解 逻辑式
Haskell Agda 文章评论 王垠

#fix #Cplusplus 这里其实把 C++ 的 Lambda capture 功能弄错了，感谢一位细心读者的反馈！（我去，这么菜的频道还会有读者）

int var = 1;
++var;

auto f = [&]() { cout « var « endl; };


f();

其实这里 & 是 by ref 的 default capture
= 才是 by value 的...（说起来这很 immediate 嘛，两个符号语义明显有区别，这是我一时脑抽了...）

若想详细了解，我写了个例子
编译结果可以在这里查看

#include <iostream>
using namespace std;

int main() {
int var = 1;
auto f = [&]() { cout << var << endl; ++var; };
auto f2 = [=]() mutable { cout << var << endl; ++var; };
//...
}

（同时感谢细心读者的建议）然后在 [&] by ref 的时候有一个要注意的问题，就是从存储对象的『生命周期 lifetime』来看如果 local variable 实际生存期比 Lambda 短，那 lambda 访问时就会出现悬垂指针（dangling pointer）的问题，这一点需要注意

同样我也写了个例子

std::function<void()> higherOrder() {
int upvalue = 0xcafebabe;
return [&]() { printf("Wow! I got upvalue = %i\n", upvalue); };
}

可以在这里阅读 [它的 cppinsight]

其实无视百度公司的其他行为来看，百度学术(xueshu.baidu.com) 还是可以用的

但是他们不重视知识产权，没有对知识最基本的敬畏，到了学术界还是一副对作者的权利的爱理不理的样子... 和以前对那些歌曲一个态度

它太强调免费了... 听起来就像是百度的尿性，养成了那么多死看着免费免费自 high 的网民，改不了啊。

这里有一个例子：

http://xueshu.baidu.com/usercenter/paper/show?paperid=e0f4dfe28ad3be0897827fb00ad16791
http://www.cnki.com.cn/Article/CJFDTotal-SJSJ404.005.htm 知网上也可以免费获取 PDF 拷贝

无关内容：谁知道这个 “CM”(Concurrent Miranda) 是不是蛤为“编译组”的 #huawei

能用咕咕噜用咕咕噜
不能用咕咕噜为什么不问问神奇的必应呢
再加上强行推广狗屎百家号
再加上百度学术也是狗屎除了免费下载屁用没有
再加上至今不肯全站 SSL
而且必应搜中文的结果水平和百度差距不大（甚至更好 包括找题目解析）
垃圾百度（和大数字啊神马啊乱七八糟的）越早扔掉越好

#paper 黄林鹏, 倪德明. 并发函数式语言CM的设计及实现[J]. 计算机工程与设计, 1994(4):38-45.

#recommended #blog https://lfkdsk.github.io/2017/09/11/quick-learn-skip-list/ #data #algorithm

Schoolar 上可以找到和华为所谓 HCC 和 CM、某优化技术什么的相关的内容，但很可惜，都是基本不沾边，只是引用甚至部分内容里稍微提了下华为，而 research 也不是华为弄的

Compiler-inserted predicated tracing
https://patents.google.com/patent/US20110154309A1/en

Compiler with energy consumption profiling
https://patents.google.com/patent/US20090037887A1/en

然后这篇蛤为的论文就是某优化编译算法之前的理论？

Application scenario identification method, power consumption management method, apparatus, and terminal device
应用程序的应用情景识别、功耗管理控制、设备和移动终端
https://patents.google.com/patent/US9813297B2/en