c++ 当然可以啊。所以我自己一直以上面写的那些思路在写程序的。

我写的程序很少出现什么内存泄露和因为指针引起的崩溃。就简单使用 RAII 规则搭配有栈协程。

不过效率上，Qt 的 COW 数据结构不够高效。甚至协程的程序，应该尽可能使用申请在栈上面的 string:

class string
{
private:
    int len;
    char buf[len];
};

大量使用协程的程序，更需要的是值类型。

总之，我上面提到的思路是一个全方面的方案。值得创新个新的语言出来。

【 在 milksea 的大作中提到: 】
: c++现在就行吧，executor用单线程的。rust的调度器也是可定制的，看用什么库了。
: c++和rust这样的语言在定位上就是要满足各种不同需求的，任务调度在不同项目里要求不一样。你这些想法都是库开发的问题。
--
FROM 110.84.123.*

就需要个协程。

我把这个思维方式应用在我们一些服务端业务逻辑开发上。比如我手头有个 OLAP 的小型数据库。有了协程以后，我整个程序结构很简单，每个数据集开个线程，相互独立。每个数据集都有很多请求，每个请求过来是一个协程。

               thread1 (workset1)
process -->    thread2 (workset2)
               thread3 (workset3)   --->  fiber1 (request)
                                    --->  fiber2 (request)

数据集我弄了个 shared_ptr<WorkingSet>，每个用于处理协程的请求都保持它的一份引用。更新数据集时，是替换这个 shared_ptr<> 而不是直接更新它——当然，我这个技术是适配我这种多读少写的情况。如果是多读多写，那得用 rust 的 btree map 那种支持 cow 的数据结构才对。但思路都一样。

上面几个 thread 虽然相互是独立的，但我用了线程间 RPC blocking queue，类似于 golang 的 chan，修改另外一个 workset 时，不需要搞序列化与反序列化，非常快。

每个请求一个协程，当这个请求结束时，各种资源跟着这个协程的销毁一起销毁了。我没感觉到管理资源有啥难度。

【 在 milksea 的大作中提到: 】
: 你这个思路需要什么语言机制么？看着像底层库开发
--
修改:hgoldfish FROM 110.84.123.*
FROM 110.84.123.*

我是是你这些不需要c++语言为你做什么改变啊
【 在 hgoldfish 的大作中提到: 】
: 上面那个帖子讲了一个例子。
:
: 我手头还有几个 PC 端的程序，用也是协程，但是因为混入 GUI 的事件循环，看起来就复杂了一些。但是基本情况也差不多。就是有事件过来，如果有 IO，我就启动协程。事件处理完成，协程也被销毁了，使用到的（内存）资源也跟着销毁。
: ...................
--
FROM 114.246.237.*

cow是个难题，我也没想好怎么弄COW。
【 在 hgoldfish 的大作中提到: 】
: 这些机制都是我自己弄出来的。在 c++ 语言社区还不普及。而且像我前面说的，c++ 标准库里面没有 cow 的 btree map.
: 如果最终能够形成一个新语言来完美实现这一整套的思路会更好一些。如果没有，我现在也用得挺舒服的，并不需要用 rust 来解决那些对我不存在的问题。
: 这就是我瞄了 rust 几眼得出的结论。不喜欢 rust 的，又觉得 c++ 有很多问题的程序员可以考虑考虑我这个方向。
: ...................
--
FROM 221.218.60.*

没研究那么深。用的btree，修改时锁死，独享，不让别人动。不知道能否达到COW的效果。
【 在 hgoldfish 的大作中提到: 】
: 我前面有介绍了两种实现 cow 的方式啊。一种是类似于 Qt 的 QString, QByteArray 这些数据结构使用的，它其实就是个 shared_ptr<> d，读这个数据结构之前，拿住引用。那么写数据结构之前 memcpy() 复制一份内容，修改完修改这个 shared_ptr<> d 不会影响读。
: 另外一种是使用 b-tree，这种数据结构能够做到 cow 修改。所以普通地被各种数据库使用。rust 使用 b-tree 来实现 treemap，而 c++ 则是使用 rb tree，python 使用 hash table.
: 上次有人测过，说 btree map 的数据局部性更好，对 cpu cache 更友好，运行效率更快。不知道是不是真的。
: ...................
--
FROM 221.218.60.*