使用 ScopeGuard 真的会带来更好的代码吗？

Question

我多年前偶然发现了 Andrei Alexandrescu 和 Petru Marginean 撰写的这篇文章，其中介绍并讨论了称为 ScopeGuard 的实用程序类，用于编写异常安全代码。 我想知道使用这些对象进行编码是否真的会产生更好的代码，或者是否会混淆错误处理，因为也许守卫的回调会更好地呈现在 catch 块中？ 有人有在实际生产代码中使用这些的经验吗？

Answer 1

是的。

它在 C++ 中非常重要，甚至在 D 中也有特殊的语法：

void somefunction() {
    writeln("function enter");
    // c++ has similar constructs but not in syntax level
    scope(exit) writeln("function exit");

    // do what ever you do, you never miss the function exit output
}

Answer 2

我没有使用过这个特定的模板，但我以前使用过类似的模板。 是的，与以不同方式实现的同样健壮的代码相比，它确实会导致更清晰的代码。

Answer 3

我不得不说，不，不，事实并非如此。 这里的答案有助于证明为什么这是一个真正糟糕的想法。 资源处理应该通过可重用的类来完成。 他们通过使用作用域保护所实现的唯一一件事就是违反了 DRY 规则，并在整个代码库中复制了资源释放代码，而不是编写一个类来处理资源，然后就这样了。

如果范围保护有任何实际用途，那么资源处理不是其中之一。 在这种情况下，它们远远不如普通的 RAII，因为 RAII 是重复数据删除的，并且自动和范围防护是手动代码复制或破坏。

Answer 4

我的经验表明，scoped_guard 的使用远远不如您可以手工编写的任何简短的可重用 RAII 类。

在尝试 scoped_guard 之前，我已经编写了 RAII 类来

• 将 GLcolor 或 GLwidth 设置回原始值，一旦我绘制了形状，
• 请确保文件已 fclosed 一旦我已经fopen编辑了它。
• 在执行慢速函数期间将鼠标指针更改为 gears/hourgrlass 之后，将鼠标指针重置为其初始状态
• 一旦我将 QListView 的 sorting 状态重置回其之前的状态暂时完成了更改其 QListViewItems - 我不希望每次更改单个项目的文本时列表都会重新排序...

使用简单的 RAII 类

这是我的代码的样子 -精心设计的 RAII 类：

class scoped_width {
    int m_old_width;
public:
    scoped_width(int w) {
        m_old_width = getGLwidth();
        setGLwidth(w);
    }
    ~scoped_width() {
        setGLwidth(m_old_width);
    }
};

void DrawTriangle(Tria *t)
{
    // GLwidth=1 here

    auto guard = scoped_width(2); // sets GLwidth=2

    draw_line(t->a, t->b);
    draw_line(t->b, t->c);
    draw_line(t->c, t->a);

    setGLwidth(5);

    draw_point(t->a);
    draw_point(t->b);
    draw_point(t->c);

}  // scoped_width sets GLwidth back to 1 here

scoped_width 的实现非常简单，并且非常可重用。
对于消费者来说也非常简单且可读。

使用 scoped_guard (C++14)

现在，使用 scoped_guard，我必须捕获引入器 ([]) 中的现有值为了将它传递给守卫的回调：

void DrawTriangle(Tria *t)
{
    // GLwidth=1 here

    auto guard = sg::make_scoped_guard([w=getGLwidth()](){ setGLwidth(w); }); // capture current GLwidth in order to set it back
    setGLwidth(2); // sets GLwidth=2

    draw_line(t->a, t->b);
    draw_line(t->b, t->c);
    draw_line(t->c, t->a);

    setGLwidth(5);

    draw_point(t->a);
    draw_point(t->b);
    draw_point(t->c);

}  // scoped_guard sets GLwidth back to 1 here

上面的内容甚至在 C++11 上都不起作用。
更不用说试图以这种方式将状态引入 lambda 会伤害我的眼睛。

使用 scoped_guard (C++11)

在 C++11 中，您必须执行以下操作：

void DrawTriangle(Tria *t)
{
    // GLwidth=1 here

    int previous_width = getGLwidth();  // explicitly capture current width 
    auto guard = sg::make_scoped_guard([=](){ setGLwidth(previous_width); }); // pass it to lambda in order to set it back
    setGLwidth(2); // sets GLwidth=2

    draw_line(t->a, t->b);
    draw_line(t->b, t->c);
    draw_line(t->c, t->a);

    setGLwidth(5);

    draw_point(t->a);
    draw_point(t->b);
    draw_point(t->c);

}  // scoped_guard sets GLwidth back to 1 here

如您所见，

• scoped_guard snoppet 需要

  • 3 行用于保留先前的值（状态）并将其设置为新值，并且
  • 2 个堆栈变量（同样是 previous_width 和 guard）来保存先前的状态

• 手工制作的RAII类需要

  • 1 个可读行，用于设置新状态并保留前一个状态，并且
  • 1 个堆栈变量 (guard) 用于保存先前的状态。

结论

我认为诸如此类的示例

void some_function() {
    sg::scoped_guard([](){ cout << "this is printed last"; }

    cout << "this is printed first";
}

并不能证明 scoped_guard 的有用性。

我希望有人能告诉我为什么我没有从 scoped_guard 获得预期的收益。

我相信通过编写简短的手工制作的类可以更好地利用 RAII，而不是使用更通用但难以使用的 scoped_guard

Answer 5

我经常使用它来保护内存使用，即从操作系统返回的需要释放的东西。 例如：

DATA_BLOB blobIn, blobOut;
blobIn.pbData=const_cast<BYTE*>(data);
blobIn.cbData=length;

CryptUnprotectData(&blobIn, NULL, NULL, NULL, NULL, CRYPTPROTECT_UI_FORBIDDEN, &blobOut);
Guard guardBlob=guardFn(::LocalFree, blobOut.pbData);
// do stuff with blobOut.pbData

Answer 6

我认为上述答案缺少一个重要的说明。 正如其他人指出的那样，您可以使用 ScopeGuard 来释放分配的资源，而不受故障（异常）的影响。 但这可能不是您想要使用作用域防护的唯一目的。 事实上，链接文章中的示例使用 ScopeGuard 来实现不同的目的：交易。 简而言之，如果您有多个需要保持某种相关状态的对象（即使这些对象正确使用 RAII），它可能会很有用。 如果任何这些对象的状态更改导致异常（我认为这通常意味着其状态没有更改），则需要回滚所有已应用的更改。 这会产生它自己的一系列问题（如果回滚也失败怎么办？）。 您可以尝试推出自己的类来管理此类相关对象，但随着这些对象数量的增加，它会变得混乱，并且您可能会回退到在内部使用 ScopeGuard 。

Answer 7

它肯定会改进你的代码。 您暂时提出的主张（它很晦涩并且代码值得使用 catch 块）在 C++ 中根本不正确，因为 RAII 是一种既定的习惯用法。 C++ 中的资源处理是通过资源获取来完成的，垃圾收集是通过隐式析构函数调用来完成的。

另一方面，显式的 catch 块会使代码膨胀并引入微妙的错误，因为代码流变得更加复杂并且资源处理必须显式完成。

RAII（包括 ScopeGuard）在 C++ 中并不是一种晦涩的技术，而是牢固确立的最佳实践。

Answer 8

是的。

如果有一段 C++ 代码我可以推荐每个 C++ 程序员花 10 分钟学习，那就是 ScopeGuard（现在是免费提供的 Loki 库）。

我决定尝试对我正在开发的小型 Win32 GUI 程序使用 ScopeGuard（稍作修改）版本。 您可能知道，Win32 有许多不同类型的资源，需要以不同的方式关闭（例如，内核句柄通常使用 CloseHandle() 关闭，GDI 需要 BeginPaint() 关闭）与 EndPaint() 等配对）我将 ScopeGuard 与所有这些资源一起使用，并且还使用 new 分配工作缓冲区（例如，用于与字符集之间的字符集转换）统一码）。

让我惊讶的是程序的短程度。基本上，这是双赢的：您的代码变得更短，同时更健壮。 未来的代码更改不会泄漏任何内容。 他们就是不能。 多么酷啊？