- 主题:lambd表达式对已析构对象为啥不抛异常
我阅读了那个帖子，非常棒，他讲述的很清晰，感谢你提供的这些。
对于这段Python，我贴出来的原因是它和CPP所犯的错误是相似的，而对于Python的使用者而言，它在Python的文档中的的常见问题中被回答，对于期望深入了解的开发者，可以使用dis包的dis来获取字节码，希望更想深入解释器，那这需要另行讨论。
我期望用此说明楼主所提供的CPP代码中的错误并非由使用带有gc语言所造成的惯性而带来的。
对于CPP这段代码，我希望说明其不抛异常原因并推测其这样做的原因。
【 在 z16166 的大作中提到: 】
:
: 楼主列的C++的例子是非常简单而且典型的，看看汇编代码也能知道
:
: python的代码，不好去看解释器的实现，顶多是加点打印变量地址的代码输出看看，然后就是一些解释器的实现的原则性描述。Ned Batchelder总结了几条，比较清楚，帖子标题是Facts and myths about Python names and values，贴不了URL了
:
#发自zSMTH@CDU.MP
--
FROM 113.143.107.*
C++编译器是不做变量的生命周期检查的，都是由码农来做这件事情，顶多有一些静态、动态检查工具可能会做。
所以编译期并不会发现这种问题。Rust编译器通过生命周期标记、类型推导以及move语义来检查这种问题。
运行期如果出问题，主要是靠CRT代码以及OS提供的异常处理API，但有些问题不一定能被CRT和OS API捕捉到，比如引用了已经被释放的内存但是并未导致access violation异常。
【 在 VincentGe 的大作中提到: 】
: 我阅读了那个帖子，非常棒，他讲述的很清晰，感谢你提供的这些。
: 对于这段Python，我贴出来的原因是它和CPP所犯的错误是相似的，而对于Python的使用者而言，它在Python的文档中的的常见问题中被回答，对于期望深入了解的开发者，可以使用dis包的dis来获取字节码，希望更想深入解释器，那这需要另行讨论。
: 我期望用此说明楼主所提供的CPP代码中的错误并非由使用带有gc语言所造成的惯性而带来的。
: ...................
--
FROM 123.118.184.*
大量请求来了这种拷贝可能给你搞挂了
【 在 frosen (WinterSweet) 的大作中提到: 】
: move是作为底层支持的
: 不是说在业务逻辑里显式调用
: 简单点说就是普通业务逻辑全走传值！
: 最差情况就是拷贝没被编译器优化成move
--
FROM 114.254.2.*
讲真，很多所谓的程序员，连函数是被同步呼叫还是异步呼叫都不知道，就疯狂用智能指针，疯狂传引用。
然后反过来抱怨，不检查生命周期，这jb怎么检查？
要么专业性不够，要门使用场景不对，除了甩锅就知道甩锅
【 在 z16166 的大作中提到: 】
: C++编译器是不做变量的生命周期检查的，都是由码农来做这件事情，顶多有一些静态、动态检查工具可能会做。
: 所以编译期并不会发现这种问题。Rust编译器通过生命周期标记、类型推导以及move语义来检查这种问题。
: 运行期如果出问题，主要是靠CRT代码以及OS提供的异常处理API，但有些问题不一定能被CRT和OS API捕捉到，比如引用了已经被释放的内存但是并未导致access violation异常。
: ...................
--
FROM 220.191.35.*
你不是大陆的啊？大陆一般不说呼叫，哈哈
【 在 ziqin (子青|会挽雕弓如满月|西北望|射天狼) 的大作中提到: 】
: 讲真，很多所谓的程序员，连函数是被同步呼叫还是异步呼叫都不知道，就疯狂用智能指针，疯狂传引用。
:
: 然后反过来抱怨，不检查生命周期，这jb怎么检查？
:
--
FROM 114.246.237.*
我就是大陆的……只不过以前是在老美的圈子……invoke和call的区别，习惯性用call
【 在 z16166 的大作中提到: 】
: 你不是大陆的啊？大陆一般不说呼叫，哈哈
: --
: 发自xsmth (iOS版)
--
FROM 60.191.0.*
call==调用
【 在 ziqin 的大作中提到: 】
: 我就是大陆的……只不过以前是在老美的圈子……invoke和call的区别，习惯性用call
--
FROM 111.206.214.*
那invoke叫什么?
【 在 blessman 的大作中提到: 】
: call==调用
--
FROM 60.191.0.*
没区别。。
【 在 ziqin 的大作中提到: 】
: 那invoke叫什么?
--
FROM 111.206.214.*
The reason is
the stack frame pointer is not destroyed
even though destructor function of temporary my_class in second loop is called.
when lifetime of a temporary object is ended, c++ make sure the destructor function is called, not the address of that object is marked as invalid.
【 在 Algoquant 的大作中提到: 】
: 把对象捕获绑定在lambda表达式里，对象已经析构了，在调用lambda时不抛异常，按UB处理，这是大坑啊。
: 我发现对这种情况，只能用 enable_share_from_this 来搞，把对象指针shared_ptr<T>托管到队列或者数组里，异步适时再调用该对象的成员函数。 （我的场景：每个算法对象订阅行情，并在收行情数据后调度器按每个股票快照 调用每个算法对象的onMarketDepth(const MarketDepth& md)，这里面就涉及每次调度时，算法对象算法是否还存活）
: #include <iostream>
: ...................
--
修改:mvtec FROM 64.44.118.*
FROM 64.44.118.*