1

我想知道是否可以配置 c++ 编译器，以便在有人设置 scoped_lock 但忘记将其分配给变量时发出警告。

请参阅以下示例：

  • 案例 1.1 和案例 2.1 展示了 scoped_lock 的预期用途
  • 案例 1.2 是一个错误的使用，没有创建持有者变量。它被编译器正确检测为错误（mMutex 有一个先前的声明）
  • 案例 2.2 与案例 1.2 几乎相同的错误，但编译器没有检测到，也没有发出任何警告，尽管代码明显有问题，并且非常接近案例 1.2（当然互斥锁不起作用）。

请参见下面的代码，我已经使用 g++-4.8 和 Visual Studio 2010 对其进行了测试。它们都没有检测到故障案例 2.2。

有谁知道 case 2.2 编译的原因，以及为了让编译器将其检测为警告可以做些什么？

#include  <boost/thread/recursive_mutex.hpp>
void Mutex1()
{
  boost::recursive_mutex mMutex;

  //Case 1.1 : correct mutex creation
  boost::recursive_mutex::scoped_lock lock(mMutex);

  //Case 1.2 : incorrect mutex creation
  //==> leads to a compile error : "mMutex has a previous declaration" : perfect
  boost::recursive_mutex::scoped_lock(mMutex);    
}

class FooMutex
{
    boost::recursive_mutex mMutex;
    void TestMutex()
    {
        //Case 2.1 : correct mutex creation
        boost::recursive_mutex::scoped_lock lock(mMutex);//compiles correctly => ok

        //Case 2.2 : incorrect mutex creation
        //is compiled without warning ! Ouch !!!
        boost::recursive_mutex::scoped_lock(mMutex);
    }
};
4

2 回答 2

3

这一行：

boost::recursive_mutex::scoped_lock(mMutex);

相当于这一行：

boost::recursive_mutex::scoped_lock mMutex;

因此，编译器警告或错误会是什么？在第一种情况下，这是一个错误，因为您正在尝试重新声明mMutex，但在第二种情况下，它是完全合理的代码，因为scoped_lock它是默认可构造的。仅对函数中的特定逻辑是错误的。编译器无法读懂你的想法。

如果您想简单地防止 ascoped_lock被默认构造，您可以自己制作不是：

template <typename T>
struct my_unique_lock : boost::unique_lock<T> {
     using boost::unique_lock<T>::unique_lock;

     my_unique_lock() = delete;
};

struct my_recursive_mutex : boost::recursive_mutex {
    using scoped_lock = my_unique_lock<my_recursive_mutex>;
};

那样，

my_recursive_mutex mMutex;
{
    my_recursive_mutex::scoped_lock(mMutex);
}

不会编译，因为默认构造函数是deleted。

于 2015-07-23T15:48:35.567 回答
0

实际上 g++ 可以为此提供警告：-Wshadow

g++ -Wall -Wshadow test.cpp -lboost_thread-mt -l boost_system

请参阅：如果在函数中重新声明成员变量，则 C++ 警告

对于铿锵声：-Wshadow-ivar

于 2015-07-23T19:22:46.167 回答