Запрещение создания временных объектов

Компилятор не должен запрещать создание временных объектов, ИМХО.

Особенно в таких случаях, как сокращение вектора, вам действительно нужен временный объект для создания.

std::vector<T>(v).swap(v);

Хотя это немного сложно, но пересмотр кода и модульное тестирование должны решить эти проблемы.

В противном случае, вот решение одного бедняка:

CSingleLock aLock(&m_criticalSection); //Don't use the second parameter whose default is FALSE

aLock.Lock();  //an explicit lock should take care of your problem

Я вижу, что за 5 лет никто не придумал самое простое решение:

#define LOCK(x) CSingleLock lock(&x, TRUE);
...
void f() {
   LOCK(m_criticalSection);

И теперь используют только этот макрос для создания замков. Больше нет никаких шансов создать временных! Это дает дополнительное преимущество, заключающееся в том, что макрос может быть легко дополнен для выполнения любого вида проверки в сборках отладки, например, для обнаружения неподходящей рекурсивной блокировки, записи файла и строки блокировки, и многого другого.

Во-первых, Эрвикер делает несколько хороших замечаний - вы не можете предотвратить каждое случайное неправильное использование этой конструкции.

Но в вашем конкретном случае это действительно может избегать. Это потому, что C ++ делает одно (странное) различие в отношении временных объектов: Бесплатные функции не могут принимать неконстантные ссылки на временные объекты. Итак, чтобы избежать появления и исчезновения блокировок, просто переместите код блокировки из конструктора CSingleLock в бесплатную функцию (которую вы можете подружить, чтобы не показывать внутренние компоненты как методы) :

class CSingleLock {
    friend void Lock(CSingleLock& lock) {
        // Perform the actual locking here.
    }
};

Разблокировка по-прежнему выполняется в деструкторе.

Использование:

CSingleLock myLock(&m_criticalSection, TRUE);
Lock(myLock);

Да, это немного сложнее для написания. Но теперь компилятор пожалуется, если вы попробуете:

Lock(CSingleLock(&m_criticalSection, TRUE));   // Error! Caught at compile time.

Поскольку параметр неконстантной ссылки Lock () не может связываться с временным.

Возможно, удивительно, что методы класса могут работать с временными объектами - поэтому ] Lock () должна быть бесплатной функцией. Если вы отбросите спецификатор friend и параметр функции в верхнем фрагменте, чтобы сделать Lock () методом, то компилятор с радостью позволит вам написать:

CSingleLock(&m_criticalSection, TRUE).Lock();  // Yikes!

MS COMPILER NOTE : Версии MSVC ++ до Visual Studio .NET 2003 некорректно разрешали функциям связываться с неконстантными ссылками в версиях до VC ++ 2005. Это поведение было исправлено в VC ++ 2005 и выше .

s почему Lock () должна быть бесплатной функцией. Если вы отбросите спецификатор friend и параметр функции в верхнем фрагменте, чтобы сделать Lock () методом, то компилятор с радостью позволит вам написать:

CSingleLock(&m_criticalSection, TRUE).Lock();  // Yikes!

MS COMPILER NOTE : Версии MSVC ++ до Visual Studio .NET 2003 некорректно разрешали функциям связываться с неконстантными ссылками в версиях до VC ++ 2005. Это поведение было исправлено в VC ++ 2005 и выше .

s почему Lock () должна быть бесплатной функцией. Если вы отбросите спецификатор friend и параметр функции в верхнем фрагменте, чтобы сделать Lock () методом, то компилятор с радостью позволит вам написать:

CSingleLock(&m_criticalSection, TRUE).Lock();  // Yikes!

MS COMPILER NOTE : Версии MSVC ++ до Visual Studio .NET 2003 некорректно разрешали функциям связываться с неконстантными ссылками в версиях до VC ++ 2005. Это поведение было исправлено в VC ++ 2005 и выше .

Нет, нет способа сделать это. Это приведет к поломке почти всего кода C ++, который в значительной степени зависит от создания безымянных временных файлов. Единственное решение для определенных классов - сделать их конструкторы закрытыми, а затем всегда создавать их с помощью какой-то фабрики. Но я думаю, что лекарство хуже болезни!

Я так не думаю.

Хотя это неразумно - как вы выяснили с помощью своей ошибки - в заявлении нет ничего "незаконного". Компилятор не имеет возможности узнать, является ли возвращаемое из метода значение «жизненно важным».