c – 可能的评估订单或Scott Meyers提供的资源泄漏是错误的吗？

发布时间：2020-12-16 10:00:58 所属栏目：百科来源：网络整理

导读：我正在阅读Scott Meyers撰写的Effective Modern C 14书中的std :: shared_ptr.这是一个代码,其中作者说,潜在的资源泄漏可能是： int computePriority(); // this function always throw an exception// ...processWidget(std::shared_ptrWidget(new Widget),

我正在阅读Scott Meyers撰写的Effective Modern C 14书中的std :: shared_ptr.这是一个代码,其中作者说,潜在的资源泄漏可能是：

int computePriority(); // this function always throw an exception
// ...
processWidget(std::shared_ptr<Widget>(new Widget),// (S.M): potentital
              computePriority());                  // resource
                                                   // leak

Scott Meyers说可以在新的Widget和std :: shared_ptr之间调用computePriority()函数< Widget>(expr)表达式会被评估什么会导致新的内存泄漏.不应该有一个序列点,可以保证新的Widget表达式是否被评估,然后std :: shared_ptr< Widget>(expr)将被评估？我想这是因为在我看来这是正确的：序列点在std :: shared_ptr< Widget>(expr)将评估它的所有参数(子表达式)而不进行排序并使共享指针准备就绪,然后做一些事情else(无需排序即可评估其他参数).如果这是不真实的,斯科特迈耶斯是对的(我仍然相信他,显然)
,这种行为会不正确？

是否有规则可以解释为什么这可能？我不擅长序列点,但告诉我他们的人说这应该是有效的.

解决方法

测序并不意味着即时性.
(在我上班之前,我的醒来是有序的,即使我穿好衣服并在中间吃早餐.)

对论证的评价不是相互排序的.

也不是一个参数必须在另一个参数之前完全评估,而不管顺序如何.

也就是说,在shared_ptr构造函数之前对分配进行了排序,但是这些都没有针对另一个参数进行排序,并且不能保证在分配和构造函数调用之间没有任何反应.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!