挂 BOINC。
不过，像我用 SB2 之类的……
……算了，房间里多放台机器开 BOINC、、、

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
随机点进去都能批判一番基本就差不多了。
项目？写得完？

草、贴多了，以上最后一节请无视……

@GeruzoniAnsasu 还有一个无视历史行程的流毒甚广的基本理解偏差单独挑出来说。
形式参数的“形式”跟“类型”无关。使用显式类型的语言才在函数的类型声明顺带形式参数的声明，因为决定函数类型的类型构造器（→）要求已知参数类型，不在函数声明中提供，还是要在其它位置明确，才可能允许函数类型检查。
这个节点里照日常使用，姑且都能算是这样的语言，但严格讲，C 就不强制——函数原型声明是可选的，不要求总是具有函数参数类型：
比如 int main() ，你拿 GCC 去调用 main(什么乱七八糟) 可能都过得去，Clang 倒是仍然会检查，但也不同于 int main(void) ；
其它用法参见 K&R C 古董代码。
不使用显式类型的语言里函数的绑定变量一般意义下也叫做形式参数，只不过“参数(parameter)”在某些情况有其它含义（ Lisp 方言使用参数作为动态作用域的变量，纯函数式语言使用参数表示类似 C++的模板类型参数的参数多态的类型变量），所以不怎么单独提出来说而已。这样的函数形式参数的所谓类型，可能是不需要明确把类型写出来而确定的（如 Haskell 这样默认就鼓励使用类型推断(type inference) 确定的语言），也可能因为变量不存在确定的类型而根本不存在（如 Scheme 这样使用清单类型(manifest typing) 的语言）。

最后回答 LZ 的问题。一般地，使用实际参数(actual argument) 初始化函数的形式参数(formal parameter) ，在函数被调用——带有作为操作符的函数以及函数的实际参数的后置表达式被求值时——发生。
对这个节点讨论的语言，函数这个特性（排除宏这种更一般意义上的“函数”）对实际参数的求值总是使用原始的应用序(applicative order) ，即函数的实际参数先于函数体被求值（但注意，不同实际参数之间没有“最左”的保证），因此（借用 C++11 和 C11 照抄 C++11 的概念）初始化总是后序于(sequenced after) 函数调用的实际参数求值之后。

一般地，函数的形式参数(formal parameter) 在

@mutalisk 放寄存器了就没人权了？
@GeruzoniAnsasu 扯蛋。
形式参数在 C/C++/Obj-C 的抽象机语义里就是特殊的局部对象 /变量，你调用了还能跳过初始化？行，试试证明不初始化不改变语义？
所谓“形式”的含义，是指不同调用实例中的实际参数能具有一对多的对应关系。不管是使用作为所谓实际参数的表达式进行绑定变量的替换或者利用活动记录的存储的代换，对“形式”不形式而言，说穿了都是实现。没有因为变量替换（更确切地，capture-avoiding substitution ）在历史上更早就更抽象的道理；况且这个节点里的语言全部不使用变量替换，而在语义上直接要求非一等的环境（局部变量的活动记录帧）外加允许一些 as-if rule （如 C++引用不要求占用存储）的变换。
如果无视这些要求，按原始的 λ 演算的语义，你都可以说这里要求的替换是无副作用的，替换的操作不存在影响可观察行为的计算作用，直接把初始化的概念取消得了。

我自己用的……demo：
https://github.com/FrankHB/YSLib/tree/master/YDE
但是现阶段没提供工具基本比 Qt 蛋疼（虽然疼的地方不一样）。
其实 Qt 也就是那么几个 dll 嘛，，，

你这是只打算用 Win32 ？一次性方案？还不如自己日 UpdateLayeredWindow 了。

看来又是个 ALGOL-like 语言学残的……补习一下历史罢。
世界上本来就没什么正经的函数(function) ，先是在 1930 年代 A.Church 提出 λ 演算里用于替换绑定变量为其它表达式的 λ 抽象以及把 λ 抽象绑定到一个名称作为变量的用法，后是 1950 年代 J.McCarthy 明确用这样的方法，来实现的一般意义上的所谓的函数。这样，λ 抽象实质上就是所谓的匿名函数(anonymous) 。（在原始的 λ 演算中，这些匿名函数都是所谓的纯函数(pure function) ，之后有另外的扩展，但这个意义上正经地搞是在 1970 年代以后的事。）
之后（从 1950 年代末开始），一坨不上道的 ALGOL-like 语言把函数弱化成过程(procedure) 乃至子例程(subroutine) 偷换概念，让函数总是总是具有所谓的函数名，先接触这类语言入门的用户就被念歪经的设计整残了；如 Java 之流的更叒鸡的语言把过程继续阉割，去掉了所谓的自由函数(free function) ，叠床架屋依附于所谓的对象（原本对象就跟类的实例无关，考虑到 Java 照抄某些语言的历史，这里是牵强附会）之上，搞出什么方法(method) ，数典忘祖；于是用这样的语言入门的用户更加不会正常的思维方式了。现在一坨语言重新引入 lambda 表达式来表达 λ 抽象，说到底不过是矫治习惯不正常的理解困难的设计的症状，要求端正视听罢了——只不过很遗憾，因为兼容和历史包袱，已有的半残的“函数”或者更残废的“方法”的语法还是被保留，以至于理解起来更容易迷糊和浪费时间。
（至于在子例程以外的函数的其它实现，如 coroutine 和 continuation 也是很早的支线，比 Java 资格老大概 30 年，这里按下不表，等 Java 之流的语言先赶上再说。）

当然，不够正经的、歧义满天飞的所谓函数数学早已有之，历史上翻来覆去倒腾了几百年也没个谱，后来才发现严格意义上可以是一回事（例如，以所谓可计算函数(computable function) 作为模型)： https://en.wikipedia.org/wiki/History_of_the_function_concept
和这样的模型比较接近的是一般大学高等数学会教你的基于 Cartesian product 模型化的映射(map) 。数学中更常见的所谓的“函数”和泛函(functional) 都是其缩水版，要求值域是实数，这在日常应用中往往是多余的限制；高中用的“函数”的 Dirchlet 定义，更是连定义域都锁死了，也不讲上域(codomain) ；除了数理逻辑讨论的一些概念，对语法和语义的分割也聊胜于无。所以对理解关心如何用代码的描述和解决计算问题的角度来说，用这些不够严格的传统数学概念，大多讲了白讲。
现代编程语言常规支持表达的某一类偏可计算函数(partial computable function)，除了不可解度（不超越图灵完备）以外，比映射能实现的计算作用(computational effect) 更强，例如允许副作用(side effect) ，也不要求是全函数(totality) 保证确定性终止。（倒是某些 FP 语言会别有用心地妄想把其中某几个特性干掉给阉回去。） Java 之流虽然叒鸡，但是比起来还算是比较正经的了。

@zunceng Phabricator 我一直有计划要上的，主要是看 BitBucket 都要下线 hg 了，找公用的 hosting site 还不如自己内部直接维护全套的。不过这玩意儿整个部署起来还是麻烦，而且也没法解决 VCS 内部不能感知 diff 语义的更根本的问题。可能总有一天这部分也得自己造轮子了。

@shmilypeter 不需要，路灯还要基建成本，抽 100%所得税就行了。

偶尔就算了……不过我还看到有单休周末固定开会+团建的，就比较费解了。

印象中比较有存在感的就是个 MSRA，不过（几年前）据说很坑：
http://m.newsmth.net/article/Microsoft/60544?p=1