我是不到万不得已不用shared_ptr
--
FROM 61.48.14.*

嗯。我就打算发明个语言，语法和 python 差不多。但不完整，只是真子集。实际上是 c++ 主义，最终编译到 exe. 最近没事就叫 AI 写几段。

它就默认用 shared_ptr<>, 自动探测场景优化成 unique_ptr<>

;-)

【 在 stub 的大作中提到: 】
: 我是不到万不得已不用shared_ptr
--
修改:hgoldfish FROM 120.37.23.*
FROM 120.37.23.*

就是默认 shared_ptr<> 但是发现这个变量只用于函数传递过程中，没有生命周期的逃逸。那就直接优化成 unique_ptr<> 就行了。其实我还进一步优化到申请在栈里面。

在我的编程语言里面，因为原生支持协程，所以几乎不存在回调函数指针 lambda 这些。变量的生命周期非常好管理。

我现在写 C++ 实际上已经使用我自己这一套思维。实践下来，变量生命周期发生逃逸一般只出现在启动协程。此时需要用到 shared_ptr<>

    filenames: list[str] = [...]
    error = ptr[str]()
    fiber = spawn(self.send_many_files, filenames, error)
    # 干点其它事。
    fibler.join()
    if s := error.value():
        print("error occured:", s)

可以看到上面 filenames 和 error 两个变量的生命周期跳出了当前函数。我的想法是大不了就复制一份 (list 使用 cow 技术)，实在不行就用 ptr[] 来传递。

【 在 stub 的大作中提到: 】
: 自动探测化场景啥意思
--
修改:hgoldfish FROM 120.37.23.*
FROM 120.37.23.*

智能指针不是为了释放资源的吗？即使没回调函数，也有释放资源的需要

Rust的borrow推导也是从另一个角度干的类似的事情，追踪引用的计数，但区分了read、write


【 在 hgoldfish 的大作中提到: 】
: 在我看来，智能指针、各种泛型编程，都是大量使用回调函数的后遗症。本来就不应该存在。
:
--
修改:z16166 FROM 123.115.134.*
FROM 123.115.134.*

生命周期短的，或者自己知道只有哪几个地方用的，如果计算量大，裸指针效率更高，这玩意不需要卡那么死
--
FROM 219.142.253.*