C++ 中 golang 样式延迟范围保护的性能答案

【问题标题】：Performance of golang style defer scope guard in C++C++ 中 golang 样式延迟范围保护的性能
【发布时间】：2020-01-01 13:33:29
【问题描述】：

阅读关于在 C++ 中实现 Go 的延迟的问题后：

golang-style "defer" in C++

我对其中一个答案中给出的 go-defer like guard 子句的性能有疑问。它使用了一个 shared_ptr 删除器，它忽略了传递的对象地址。

如果删除器忽略了使用未命名参数的地址，它是否仍会在堆栈上传递。

以下任何一种方式完成defer会有什么不同吗？

#include <memory>
#include <iostream>
#include <functional>

using namespace std;
using defer = shared_ptr<void>;

int main() {
    defer defer0 (nullptr, [](...) { cout << "defer0\n"; }); // this is the version i've seen

    // but will the performance be any different using any of these?
    shared_ptr<int> defer1(nullptr, [](int* dummy) { cout << "defer1\n"; });
    shared_ptr<int> defer2(nullptr, [](int*) { cout << "defer2\n"; });
    shared_ptr<void> defer3(nullptr, [](void*) { cout << "defer3\n"; });

    unique_ptr<int,void(*)(int*)> defer4(nullptr, [](int*) { cout << "defer4\n"; });

    cout << "Hello\n";
}

【问题讨论】：

为什么不为此编写一个类而不是滥用智能指针？
它不适用于unique_ptr，因为它的析构函数不会在 null (see here) 上调用删除器

标签： c++ deferred scopeguard

【解决方案1】：

您可以在此处查看为每个实现构建的内容：godbolt。

简而言之，版本 0-3 之间没有区别，指针在每种情况下都以相同的方式传递给删除函数。

如果您正在寻找性能，则为此使用std::shared_ptr 不是一个好主意。共享指针需要为资源计数分配内存，这对于终结器来说是完全没有必要的。

std::unique_ptr 情况（使用虚拟变量，因此实际调用了删除器）将以最少的开销工作。但是，更专注的课程会更明智。

【讨论】：