- 主题:我们很多同事都是完全不用unique_ptr，一律shared_ptr
嗯。我就打算发明个语言，语法和 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.*
在我看来，智能指针、各种泛型编程，都是大量使用回调函数的后遗症。本来就不应该存在。
【 在 stub 的大作中提到: 】
: 我是不到万不得已不用shared_ptr
--
FROM 120.37.23.*
肯定不能完全兼容 python 啊。因为想兼容 python 就得实现 python 的那一套 duck type 的语义。最终会发现我们又实现一个 nuika
我想实现的语法是 c++ 语义的。只是披着 python 语法的皮。比如函数参数和变量都必须定义类型:
def sum(*nl: int) -> int:
c = 0
for n in nl:
c += n
return c
上面这个函数和 c++ 写的:
int sum(vector<int> nl) {
int c = 0;
for (int n: nl)
c += n;
return c;
}
根本没有任何区别。只是换个语法而已。
在这个基础上，我主要是想实现工程上的创新：
1. 我选取 c++ 语义的子集，自动使用智能指针。做到和 python 一样的入门门槛。
2. 编译器可直接编译 c 源代码。可使用 from c import printf 直接调用 c 语言函数。
3. 值语义，没有 None，没有 nullptr. 彻底解决空指针。
4. 超级简化版的 c++，回到 90s 的 c++ 再重新进化。
这个项目正在缓慢推进中。属于有生之年系列。不过我之前已经有一个试验版本了，可以编译并且输出 exe.
【 在 hotfix 的大作中提到: 】
: 厉害了
: 如果完全兼容python会更好
: 可以让AI用你的语言写程序
: ...................
--
修改:hgoldfish FROM 120.37.23.*
FROM 120.37.23.*
解释性语言不值钱吧。我想弄的是编译型语言。
而且 Qt 的话，不是有 PyQt 可用吗？
我之前做了个 eventlet-pyqt 的转换模式，在 PyQt 里面可直接调用 python 的各种网络库和第三方库非常方便。
没必要自己再弄个解释型语言吧。
【 在 hotfix 的大作中提到: 】
: 我想起来我前公司大佬开发了一个类C++语法的解释性语言
: 用来编写Qt 界面等程序
: : 肯定不能完全兼容 python 啊。因为想兼容 python 就得实现 python 的那一套 duck type 的语义。最终会发现我们又实现一个 nuika
: ...................
--
修改:hgoldfish FROM 120.37.23.*
FROM 120.37.23.*
那个我看过。它做的是超集。不是子集。
而且这个语法皮不重要。我的想法和现在的语言有很多不一样的地方。比如我觉得不应该搞啥静态链接了。用 dlopen() 调用 libc 比 golang 那样自己重新实现个 stdlib 方便多了。
【 在 ArchLinux 的大作中提到: 】
: 文法兼容Python的编译型语言，你可以看看Mojo.
--
FROM 120.37.23.*
哪个 ladybird? kling 大神他们搞的那个浏览器吗？
【 在 tgfbeta 的大作中提到: 】
: 直接用Swift，早用早好
: 你看隔壁ladybird就要切换到Swift
--
FROM 27.152.128.*
现在是有些人在乎，有些人不在乎。
【 在 ylh1969 的大作中提到: 】
: 是。40年前，ibmpc，4.77M主频。
: 在那机器上写程序，很在乎这点开销。
--
FROM 125.78.41.*
你不是一直用协程吗？可以用一个套路，把所有的回调都转成协程阻塞的玩法：
回调式：
void on_success(result_set) {
/* 直接处理事件 */
}
async_query(sql, on_success);
可以转成:
// 接下来三行是固定套路。
finished = new event();
void send_result(result_set) {
finished.send(result_set);
}
async_query(sql, send_result);
// 程序员专注这一行
result_set = finished.await();
没有回调，生命周期就很好协调。
其中的工具类是 Event, 它有两个方法:
Event::send(T result);
T Event::await();
它的定义是
class Event {
T result = T();
bool success = false;
Condition condition;
}
这就是把回调薅直的秘密。
【 在 ylh1969 的大作中提到: 】
: 没理解。
: 泛型编程很重要，尤其是运行时泛型，就是靠回调函数。请看C版关于泛型的帖子。
: 运行时泛型，主要两点：
: ...................
--
修改:hgoldfish FROM 125.78.41.*
FROM 125.78.41.*
这种情况怎么会用指针？
用值语义非常方便。
c++ 如今有 move 语义，这种传递数据最佳的方案就是直接返回结果，别让客户把指针传进来。虽然底层也可以理解成指针，但配合 RAII 或者 uniqure_ptr，应用层的程度员不再需要管指针了。
【 在 ylh1969 的大作中提到: 】
: 两回事。
: 这里说的是指针问题，运行时泛型要用到指针。回调函数是个指针，在泛型程序里，序列化反序列化过程需要指针，SQL语句生成器需要指针，绑定变量需要指针，收集结果需要指针，，，，
: 所有的泛型程序，接受的数据，不知道类型，一律void ＊；就是指针，而且没法用智能指针。
: ...................
--
FROM 125.78.41.*