- 主题:C++ 的很多奇葩的设计都是因为回调函数而来的
从回调函数出发，搞了 std::function<>, constexpr, auto, concept 等用于描述函数的特征。还有各种泛型编程的，都是为了代替虚函数，而虚函数本身又是回调函数的一种抽象。
所以回调真是万恶之源。如果没有回调，早点发明 co_await() 说不定就没有后面这么多事情了。
--
FROM 59.61.198.*
感觉你知识学杂了。
std::function还沾点边。解决函数是first class的问题
constexpr重点是编译期计算吧，减少运行期开销。
auto是为了类型推断，类型系统里问题。
concept也是类型系统，静态类型约束。
泛型编程也是类型系统，解决类型抽象的问题，是在算法抽象后的继续抽象。
回调是执行模型的问题，co wait打破了结构化程序的约束（for while 函数作为基本单元 早期叫procedure/routine，先有routine，再有co routine），换一种面貌出现。本质是函数不再是完整block，可以执行一半hang住，然后resume。所以一般人驾驭不了。
结构化程序是dijkstra？的主要贡献。后面还有形式化程序，一直没证明成功？
酒后凭感觉写一点。供批判。
【 在 hgoldfish 的大作中提到: 】
: 从回调函数出发，搞了 std::function<>, constexpr, auto, concept 等用于描述函数的特征。还有各种泛型编程的，都是为了代替虚函数，而虚函数本身又是回调函数的一种抽象。
: 所以回调真是万恶之源。如果没有回调，早点发明 co_await() 说不定就没有后面这么多事情了。
--
修改:DoorWay FROM 61.185.195.*
FROM 61.185.195.*
如果只有值的话，const 就够了，出现 constexpr 就是现代 c++ 里面一大堆 lambda, c++ 自己不知道这些函数能够在编译期计算出来。所以需要程序员在代码里面给点提示。
auto 也是因为很多 lambda 的类型已经不是程序员可以写出来的，要么是太长了，要么是跟着泛型编程传入的参数而变化，所以只好用 auto 让编译器自动推断。
泛型编程当年也是毒瘤。要是早点有 any，或者有 object 基类，学 Java 把 int 打包到 Integer 里面后面就不会发明这么多语法了。更不会出现 concept 这么复杂的东西。
最近我 c++ 协程用多了，发现有了协程，c++ 真的没必要搞以前那么复杂。因为已经完全不需要用回调函数了，很多功能，甚至 shared_ptr<> 的使用都大为减少。
【 在 DoorWay 的大作中提到: 】
: 感觉你知识学杂了。
: std::function还沾点边。解决函数是first class的问题
: constexpr重点是编译期计算吧，减少运行期开销。
: ...................
--
修改:hgoldfish FROM 59.61.198.*
FROM 59.61.198.*
只有第4段看懂了。前3段没这么考虑过问题。
有时间慢慢盘问AI。夹磨夹磨它。跟以前点wikipedia的链接消磨时间的乐趣一样。
【 在 hgoldfish 的大作中提到: 】
: 如果只有值的话，const 就够了，出现 constexpr 就是现代 c++ 里面一大堆 lambda, c++ 自己不知道这些函数能够在编译期计算出来。所以需要程序员在代码里面给点提示。
: auto 也是因为很多 lambda 已经不是程序员可以写出来的，要么是太长了，要么是跟着泛型编程传入的参数而变化，所以只好用 auto 让编译器自动推断。
: 泛型编程当年也是毒瘤。要是早点有 any，或者有 object 基类，学 Java 把 int 打包到 Integer 里面后面就不会发明这么多语法了。更不会出现 concept 这么复杂的东西。
: ...................
--
修改:DoorWay FROM 61.185.195.*
FROM 61.185.195.*
协程的临界区很麻烦。比如需要序列处理 容器里的使用元素：
for auto& ele : container {
co_await myfunction(ele);
}
如果 myfunction 挂起期间 ，别的线程要修改 container ，就非常麻烦 ，resume回来，如果容器修改了，就崩了。加锁，就严重和协程理念违背了
【 在 hgoldfish 的大作中提到: 】
: 如果只有值的话，const 就够了，出现 constexpr 就是现代 c++ 里面一大堆 lambda, c++ 自己不知道这些函数能够在编译期计算出来。所以需要程序员在代码里面给点提示。
: auto 也是因为很多 lambda 的类型已经不是程序员可以写出来的，要么是太长了，要么是跟着泛型编程传入的参数而变化，所以只好用 auto 让编译器自动推断。
: 泛型编程当年也是毒瘤。要是早点有 any，或者有 object 基类，学 Java 把 int 打包到 Integer 里面后面就不会发明这么多语法了。更不会出现 concept 这么复杂的东西。
: ...................
--
修改:Algoquant FROM 14.127.25.*
FROM 14.127.25.*
这个场景，就算不用携程，一样也有这个问题
【 在 Algoquant 的大作中提到: 】
: 协程的临界区很麻烦。比如需要序列处理 容器里的使用元素：
: for auto& ele : container {
: co_await myfunction(ele);
: ...................
--
FROM 114.254.115.*
没错没错。。这里就是锁的使用场景。但这个复杂度不是协程带来的，而是并发带来的。
只要你想搞并发，又要访问同一个变量。那总要用点啥机制处理。
我自己一般不加锁，而是借用 QtCore 的 Copy On Write:
for (const QString &ele: QStringList(container)) {
doSomethingSync();
}
在这里，Qt 并不会真的复制。只有另外一个协程修改了 container 的时候才会复制一次。适合读多写少的场景。写多的就没办法，加协程锁吧。协程锁也是非常轻量的。
【 在 Algoquant 的大作中提到: 】
: 协程的临界区很麻烦。比如需要序列处理 容器里的使用元素：
: for auto& ele : container {
: co_await myfunction(ele);
: ...................
--
FROM 59.61.199.*