c ++块{}会产生负面影响

Question

我最近发现{}块可以单独使用。对我来说，在某些情况下，这可能是真正的辅助可读性。例如，在以下代码中：

push();
foo();
push();
foo();
foo();
pop();
pop();

可以成为（不与IDE自动缩进对抗）：

push();
{
    foo();
    push();
    {
        foo();
        foo();
    }
    pop();
}
pop();

除了对风格的主观意见之外，这是否会产生任何负面影响（比如编译器的较少受害者，他们还有其他用途等）或者这些块是否可以安全使用。

Answer 1

当它们不改变代码的含义时（如在您的示例中），没有理由它们应该对优化产生任何影响。如果他们这样做，那么这是特定编译器的怪癖。

要强制您的pop()来电映射push()来电，您甚至可以这样做：

struct Pusher {
    Pusher() { push(); }
    ~Pusher() { pop(); }
};

...

{
    Pusher p1;
    foo();
    {
        Pusher p2;
        foo();
        foo();
    }
}

该模式通常称为RAII。它确实改变了代码的含义 - 在我的代码pop()中，如果对foo()的一个调用引发异常，则会调用{{1}}。吨。在大多数（但不是全部）需要在返回之前撤消某些内容的情况下，您还需要撤消异常。

Answer 2

关于你的第二个例子的一切都是100％罚款。额外的块可能会影响在它们中声明的变量的范围，但是你没有这样做。

Answer 3

创建这样的块会创建新的范围。因此，您将在进入和退出这些范围时运行构造函数和析构函数。您还有更多机会让名字互相隐藏。它们可以安全使用，但你必须记住这些事情。

顺便说一句，这是主观的，但我发现你对范围的使用有助于提高可读性。你可以用空行完成同样的事情。如果我在评论中看到您的代码，我会问自己为什么要创建这样的范围。

有一个范围对于与RAII style programming一起控制生命期非常有用。在此示例中，范围用于限制互斥锁保留的时间。

int a = b + c;
{
   OS::Mutex::Lock lock(mutex);
   some_shared_variable = a;
}

此处Lock是一个RAII样式类，它在构造函数中获取互斥锁并在析构函数中释放它。通过显式使用范围，您可以限制锁定的持续时间。