- 主题:异常这玩意儿当初是哪个脑残发明出来的？
说得好，但是有一个不解。
如果异常跳出了好几层函数，中间层new出的对象，是否都能析构呢？
如果都自动析构，如果抛的信息含有这些内容呢？
【 在 e729 的大作中提到: 】
: 你的思维，还局限在c的面向过程，而cpp是面向对象编程，异常作为一个对象，可以携带更多的信息。（当然，也允许只抛出一个整数或者字符串）
: 在编码的层次上，返回值可以被忽略，而抛出的异常则不可，这减少了提交给用户的产品出错的概率
: 一个函数（或者模块）抛出了一个异常，处理这个异常的代码可以调用栈中的几级以外，就是说，这期间众多的调用过程，根本无需处理异常，而你的‘返回值机制’呢？
: ...................
--
修改:ylh1969 FROM 221.218.62.*
FROM 221.218.62.*
这方法比较麻烦。而且，同样存在中间层内存泄露问题。
估计try catch 就是用的longjmp。
【 在 il15 的大作中提到: 】
: 我用c，然后用long jump，“重载”了内存和文件的操作，感觉可以把 判断返回值这种做法就去掉了。
:
--
FROM 221.218.60.*
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.*
不弄了，这事让数据库解决吧。
ORACLE有个绝招，如果统计过程中数据还在修改，他就会找日志里的老数据。不会互相锁定。这就解决了未commit的数据问题。
【 在 hgoldfish 的大作中提到: 】
: 这肯定不算 COW 啊！
: btree 数据结构你可以再研究研究一下，这个数据结构可以做到真正的 COW，是有个宝藏数据结构。
:
--
FROM 221.218.60.*
如果把树调到私有区修改，完成后拷贝回去。
期间源树加修改锁，禁止其他任务修改。
应该可以。
【 在 hgoldfish 的大作中提到: 】
: 这肯定不算 COW 啊！
: btree 数据结构你可以再研究研究一下，这个数据结构可以做到真正的 COW，是有个宝藏数据结构。
:
--
FROM 221.218.60.*
那就让数据库去弄吧，这事都交给数据库，别自己玩了。
【 在 hgoldfish 的大作中提到: 】
: 你这个玩法太山寨了。btree 的 cow 特性是各种数据结构书和数据库系统的内容。wiki 上面也有介绍。这个特性还可以和 FP 编程的 immutable 联系起来，所以我说它是个宝藏数据结构。
:
--
FROM 221.218.60.*