C++代码中的额外大括号

Question

有时您会遇到带有额外大括号的代码，这些代码与范围无关，仅用于可读性和避免错误。

例如：我已经看到了

GetMutexLock(handle) ; 
{ 
    // brace brackets "scope" the lock, 
    // must close block/remember 
    // to release the handle. 
    // similar to C#'s lock construct 
} 
ReleaseMutexLock(handle) ; 

其它地方有：

glBegin(GL_TRIANGLES) ; 
{ 
    glVertex3d(..) ; 
    glVertex3d(..) ; 
    glVertex3d(..) ; 
} // must remember to glEnd! 
glEnd() ; 

此介绍如果互斥锁没有释放一个编译器错误（假设你还记得这两个}和Release()）。

1. 这是不好的做法？为什么？
2. 如果不是这样，它是否可以改变代码的编译方式或使其变慢？

Answer 1

大括号本身很好，他们所做的只是限制范围，你不会放慢速度。它可以被视为更清洁。 （总是喜欢干净的代码了快速的代码，如果它是清洁，不用担心，直到你个人资料的速度。）

---

但是相对于资源它是不好的做法，因为你已经把自己放在一个位置泄漏资源。如果块中的任何内容抛出或返回，那么你已经死了。

使用范围限制的资源管理（SBRM，也被称为RAII），这限制了资源的范围，通过析构函数：

class mutex_lock 
{ 
public: 
    mutex_lock(HANDLE pHandle) : 
    mHandle(pHandle) 
    { 
     //acquire resource 
     GetMutexLock(mHandle); 
    } 

    ~mutex_lock() 
    { 
     // release resource, bound to scope 
     ReleaseMutexLock(mHandle); 
    } 

private: 
    // resource 
    HANDLE mHandle; 

    // noncopyable 
    mutex_lock(const mutex_lock&); 
    mutex_lock& operator=(const mutex_lock&); 
}; 

所以，你得到：

{ 
    mutex_lock m(handle); 
    // brace brackets "scope" the lock, 
    // AUTOMATICALLY 
} 

这样做是否会全部资源，它更干净，更安全。如果你有能力说“我需要释放这个资源”，那么你做错了;他们应该自动处理。

Answer 2

这不是坏习惯。它不会让任何事情变慢。这只是构建代码的一种方式。

让编译器做错误检查&为你执行永远是件好事！

Answer 3

任何提高可再生性的方法恕我直言，这是很好的做法。如果添加大括号有助于提高可读性，那就去做吧！

添加其他大括号不会改变代码的编译方式。它不会使程序的运行速度变慢。

Answer 4

大括号影响变量作用域。据我所知，这是他们所做的一切。

是的，这会影响程序编译的方式。析构函数将在块的末尾被调用，而不是等到函数结束。

通常这是你想要做的。例如，您的GetMutexLock和ReleaseMutexLock会好得多C++代码写成这样：

struct MutexLocker { 
    Handle handle; 
    MutexLocker(handle) : handle(handle) { GetMutexLock(handle); } 
    ~MutexLocker() { ReleaseMutexLock(handle); }  
}; 
... 
{ 
    MutexLocker lock(handle); 
    // brace brackets "scope" the lock, 
    // must close block/remember 
    // to release the handle. 
    // similar to C#'s lock construct 
} 

采用这种更为C++风格，锁在块结束时自动释放。它将在所有情况下被释放，包括例外情况，除setjmp/longjmp或程序崩溃或中止外。

Answer 5

除了在该块的末尾调用任何析构函数，而不是在周围块的末尾调用编译代码之外，它将不会产生任何影响，除非编译器完全疯狂。

就我个人而言，我会称之为不好的做法;避免可能出现的错误的方式是使用有限范围的资源管理（有时称为RAII），而不是使用容易出错的印刷提醒。我会写这样的代码，如

{ 
    mutex::scoped_lock lock(mutex); 
    // brace brackets *really* scope the lock 
} // scoped_lock destructor releases the lock 

{ 
    gl_group gl(GL_TRIANGLES); // calls glBegin() 
    gl.Vertex3d(..); 
    gl.Vertex3d(..); 
    gl.Vertex3d(..); 
} // gl_group destructor calls glEnd() 

Answer 6

这是更有用（恕我直言）在C++与对象析构函数;你的例子是C.

试想一下，如果你犯了一个MutexLock类：

class MutexLock { 
private: 
    HANDLE handle; 
public: 
    MutexLock() : handle(0) { 
     GetMutexLock(handle); 
    } 

    ~MutexLock() { 
     ReleaseMutexLock(handle); 
    } 
} 

，那么你可以作用域锁定只是需要它通过提供一个新的领域与括号中的代码：

Answer 7

如果你把代码放在大括号中，你应该把它分解成它自己的方法。如果它是一个单独的分立单元，为什么不标记它并在功能上分解它？这将明确说明块的功能，后来阅读代码的人不必弄清楚。

Answer 8

原始示例中的{ ... }的具体位置纯粹用于格式化糖，通过在一组逻辑相关的语句开始以及结束时更明显。如您的示例所示，它对编译的代码没有影响。

我不知道你的意思是“如果互斥体未被释放，这会引发编译器错误”。这根本不是事实。这种使用{ ... }不能也不会引入任何编译器错误。

这是否是一种好的做法是个人喜好的问题。它看起来不错。或者，您可以使用注释和/或缩进来指示代码中语句的逻辑分组，而无需额外使用{ ... }。

在这里有各种基于范围的技术，其中一些已经在这里用其他答案进行了说明，但是你在OP中拥有的东西甚至不能远程看这样的东西。再一次，你在OP中拥有的东西（如图所示）纯粹是一种源代码格式化习惯，多余的{ ... }对生成的代码没有任何影响。