@exploreexe #66 有报道偏见的成分。燃油车碰撞起火，汽油易挥发的特性，爆燃留给人逃生的时间更短。“玛莎拉蒂撞宝马案”，后排乘客被烧亡，驾驶员幸存但烧伤达 40%。新能源车电池即便起火，好歹锂电池起码不会挥发，从后排烧到前排需要一点时间，有机会逃生。只是电池起火难以扑灭，扑灭会可能再次起火。

2020 年 11 月，宝马一个月内就自燃了三辆。https://zhuanlan.zhihu.com/p/320053699
2018 年，宝马在韩国接连自燃 48 起，宝马被韩国 zf 禁止上路。https://www.unecne.com/archives/63758

即便如此，大家的印象仍然是宝马燃油车不会自燃，因为这些新闻从来不会上头条。但电车每一起火灾事故基本都成新闻头条了。

@neptuno #65 分母是总保有量，不是当年的销量。

2022 世界动力电池大会上欧盟院士、中科大教授、937 计划首席科学家孙金华表示，“目前，电动汽车起火率约为 0.03%，略高于传统燃油车。从起火汽车所处状态来看，35%处于充电状态，40%处于行驶状态，25%处于静止状态”。

美国国家运输安全委员会（ NTSB ）数据，电池电动汽车火灾的可能性仅为 0.03%，相比之下，燃油车为 1.5% ，混动为 3.4%。 https://www.renolon.com/electric-car-fire-statistics/

基于应急管理部消防救援局的数据，
2022 年 1 季度，新能源车火灾事故 640 起。https://www.119.gov.cn/article/47Sd3LDSJrA
2021 年全年，新能源汽车火灾共发生约 3000 余起。https://www.119.gov.cn/article/46TiYamnnrs
2020 年不完全统计，新能源汽车火灾共发生约 72 起。https://zhuanlan.zhihu.com/p/363323648

累计到 2022 年 1 季度，新能源火灾事故约 3800 起，同时新能源车保有量 891.5 万辆，计算为万分之 4.1 。
随着新能源车的销量迅速增加，反而（充电和行使）发生火灾的概率在不断下降，因为新的电池技术不断更安全。

只是学，很难学到理解深刻的东西。只要在项目中才能成长。我个人来说，我开始阅读 Python 的标准库源码时是进步最快的一段时间，因为发现它的那些设计都比较简单和清晰，代码很容易就能看懂；相比之下，自己设计的项目就显得很难看。

没学过 java ，不过你的设计肯定是有问题的。
基类就不应该调用派生类的任何东西，不管技术上能不能实现，你都不应该这么做。
这是一个道德性原则。

比亚迪 7 月份卖了 13 万辆，7 月份卖了 16 万辆。作为比亚迪的小股东，建议还是不要买比亚迪了，排队等车要半年。

楼上说比亚迪高自燃率，纯属尬黑。
比亚迪的销量和占有率是最高的，去年和今年已经卖了超 140 万辆。火灾事件与它的保有率相比，火灾事故率不足万分之一，火灾概率比传统油车低。

没有全职，不过我的投资收益也稳定，年化 20%+。 今年目前是 55%

房价太贵了，我手里的钱也够全款买套房，但是不值得。辛苦赚来的钱白白被剥削，跟傻子一样帮人打工。
持有股票的投资收益比买房好太多了。

@anonymous256 像 Linux/Win 这类可以“实时”交互的系统，此处的“实时”应该打个引号。因为本质上它不是实时的，是操作系统的中断程序调度出来的“伪实时”，CPU 进程调度切换太快，让用户感觉是实时的，其实不是真正的实时。

@cmu2chert 计算机执行多任务，就要考虑不同的任务之间是否允许抢占。
1. 例如批处理操作系统，它是不允许被抢占的。你提交一系列的任务，计算机会按照顺序一直到执行结束，这期间无法干预。
2. 像 Linux/Win 这类可以实时交互的系统，都是允许被抢占的。比如听着音乐，打着游戏，还能打开网页，因为新增的任务抢占了前面的任务。原理是：CPU 的计时器以固定的频率触发中断，然后 OS 执行调度算法，调度不同的进程，实现不同任务的上下文切换。

集体利益高于一切，在中国是很普遍的想法。家庭就是一个小集体。有多少人结婚、买房、生育并不是因为他们自己想要那么做，而是由于父母和家人的要求？许多人也是自愿接受了控制。这种价值观从家庭到学校、社会、公司、行政单位，无处不在。

举个例子，一个人明明几个月都没出小区，却还要强制几天一次的无意义核酸，个人的声音得不到尊重。又或者，疫苗接种明明是“自愿”的。但如果你不接种，居委会就三天两头打电话催促你，所谓“自愿”并不存在。

有共同志向的人为集体事业奉献自己，那也无可厚非。只是，有些集体以公共利益来强迫个人做奉献，规定别人的 人生。本质不是集体导向的价值观，而是法西斯。

电车。 比亚迪

我之前的邻居也是楼道养狗，经常把垃圾袋放门口。
现在整个楼的邻居都把垃圾放楼前树下，明明垃圾回收点就在 50 米的不远处。
我在拼多多定制了个“公告牌”，写了：垃圾不要扔树下，小区环境靠大家。情况稍微好了一点，但还是有人喜欢把垃圾扔旁边。拿他们没辙。

王小波-- 《居住环境与尊严》
http://www.vrrw.net/hstj/18331.html
《门前空地》
https://www.ihuaben.com/book/8188032/51963453.html
《环境问题》
https://m.fanwenxiansheng.com/article/20220320/988ea86.html

不要局限于一个小的方向吧，多关注语言自身的特性和设计，关心更多的编程语言、系统、算法，视野也就更开阔了。

油价还会继续涨价的可能性很高，因为欧盟通过了对俄罗斯的能源制裁。原油可能会涨到 150 美元以上。中国原油进口的占比是 70%+，国际油价涨，国内汽油就同等幅度跟涨。

在你的触发器函数里面，解开函数调用栈就可以了。三种常用的办法：

1. gcc 内置宏__builtin_return_address：非常粗略的低级方法。这会在堆栈上的每一帧上获得函数的返回地址。注意：只是地址，不是函数名。所以需要额外的处理来获取函数名。
2. glibc 的 backtrace 和 backtrace_symbols：可以获取调用堆栈上函数的实际符号名称。
3. libunwind 库

参考自： https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/

根据上述文章提到的办法，采用 libunwind 库，我简单修改了下它的代码:
1. 代码示例

```
// example.cpp

#include <libunwind.h>
#include <stdio.h>

// Call this function to get a backtrace.
void backtrace() {
unw_cursor_t cursor;
unw_context_t context;

// Initialize cursor to current frame for local unwinding.
unw_getcontext(&context);
unw_init_local(&cursor, &context);

// Unwind frames one by one, going up the frame stack.
while (unw_step(&cursor) > 0) {
unw_word_t offset, pc;
unw_get_reg(&cursor, UNW_REG_IP, &pc);
if (pc == 0) {
break;
}
printf("0x%lx:", pc);

char sym[256];
if (unw_get_proc_name(&cursor, sym, sizeof(sym), &offset) == 0) {
printf("(caller function: %s+, offset: 0x%lx)\n", sym, offset);
} else {
printf(" -- error: unable to obtain symbol name for this frame\n");
}
}
}

void foo1() {
backtrace(); // <-------- backtrace here!
}

void foo2() {
backtrace(); // <-------- backtrace here!
}


int main(int argc, char **argv) {
foo1(); // <-----在函数 foo1()和 foo2()中可以看到整个的调用栈。
printf("\n");
foo2();
return 0;
}

````

2. 编译前安装依赖（以 ubuntu 为例）:
sudo apt install libunwind-dev

3. 编译指令:
g++ -o example example.cpp -L /usr/local/lib -lunwind

用 handler 比用 if 会更好吗？ handler 里面不一样还是要用 if 写一堆判断？一个函数里面的内部需要返回不同的错误。

这个草案是不可能被通过的。
因为这违背了 Golang 的基本设计哲学：错误是值。
https://go.dev/blog/errors-are-values

不直接去返回那个（错误的）值，却放在 handler 里面去返回，不是在搞笑吗？这会让你同一逻辑的代码在空间上分离。比如一个函数 和它的错误处理在代码的空间上分离，这绝对更加不利于代码的可读性。if err != nil { ... } 只是丑陋了一点，但是可读性仍然是良好的。

golang ，永远不太可能有除了 if err != nil { ... } 之外的错误处理方案，因为它的设计哲学决定了这个。除非它改变设计哲学。像 Python 的做法是把错误当成异常，而不是值。

你这个问题，也是过去历代计算机科学家想要攻克的问题。你可以读一读 Dijkstra 1972 年的图灵演讲。
英文版： https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html
中译版： https://www.ituring.com.cn/article/71467

他提到了：
“论据三是建立在程序正确性问题的建设性方法上的。今天，一项普通的技术就是写一个程序，然后去测试。 尽管，程序测试是一种非常有效的方法去暴露 bugs ，但对证明不存在 bugs 几乎是完全没用的。显著提高程序可信度唯一有效的方法是给出一个令人信服的关于正确性的证据。但是我们不应该首先写出程序，然后去证明它的正确性，因为要求证明只会增加苦逼程序员的负担。相反，程序员应该让正确性证明和程序相互验证，发展。论据三本质上是从以下的观察得来的。如果一个人问自己一个令人信服的证据应该具备什么，他了解后，写了一个很好的满足了证明要求的程序，然后这些关于正确性的担心变成一种有效的启发式的指导。当我们把自己限制在智能可控程序时，按照定义，只有这种方法是可行，但这种方法也提供许多有效的方法，让我们从中挑选一个满意的。”

他的思想是测试驱动开发（ TDD ）：先写好验证的测试，把所有可能的情况考虑到，再写程序。你只需要说明你写用于测试的程序是有效的（基于合理正确的思维逻辑），只要能测试通过，那么你写的被测试的程序必然是正确的。

但这个毫无疑问会增加程序员的工作量和负担。对足够优秀的程序员来说，我觉得一定是不必要的负担。

我通常只对不稳定的函数和接口添加测试。有些函数的参数来源于不可控的外部数据源，比如要读取一个文本，读取到的数据各种可能性都有，这个时候就要添加测试程序，只是用来验证和保证被测试程序的正确性。

聊聊天啊，让他自立。
不愿意找工作，可能是找工作受了挫折，没有信心，多鼓励鼓励。
强硬点就扫地出门了，让他自己成长。