С таким способом объявления инстанса объекта Lock(&m_lock); - нигде не правильно, ибо конструктор и деструктор будут вызваны на одной и той же строчке кода.
Если бы там было Lock guard(&m_lock);
то я бы проголосовал внутрь try ибо малоли, вдруг Lock() тоже кидает исключения
Если же Lock это всетаки вызов функции а не объект, и там гдето подразумевается далее Unlock, то я голосую за в самом начале функции.
[C++] good point02.03.10 21:07 Автор: void <Grebnev Valery> Статус: Elderman Отредактировано 02.03.10 21:10 Количество правок: 1
Я тоже сначала засомневался насчет временного объекта, но решил себя проверить и быстро воткнул код в проект, что был под рукой. Сработало так, как будто объект был не временным, я даже порадовался и решил запомнить на будущее. Сейчас попробовал воспроизвести, не получилось ни там, ни на чистом проекте. Может быть, это такие шутки minimal rebuild.
Но в случае нормального объекта все-таки лучше смотреть на обработчик. Поскольку
И если класс Lock из первого поста предназначался для защиты от совместного использования некого ресурса, к которому вдруг есть обращение в обработчике исключения, первый вариант окажется надежнее.
> Я тоже сначала засомневался насчет временного объекта, но > решил себя проверить и быстро воткнул код в проект, что был > под рукой. Сработало так, как будто объект был не > временным, я даже порадовался и решил запомнить на будущее. > Сейчас попробовал воспроизвести, не получилось ни там, ни > на чистом проекте. Может быть, это такие шутки minimal > rebuild.
If the result of the code is not used somewhere further, the Microsoft compiler will strip the code (you will not find that code in *.asm), for example, the code below will not result in an exception in the release (optimized) version:
void f()
{
A a;
int b = 0;
int c = 1/b;
}
But the same code will give you an exception, if you force the compiler to leave the code { int b = 0; int c = 1/b;}
For example,
void f()
{
A a;
int b = 0;
int c = 1/b;
printf("%d", c);
}
Will it help?
Эксцепшны тут не причем. Проблема поставленного вопроса в...02.03.10 21:50 Автор: Killer{R} <Dmitry> Статус: Elderman
в таком случае - внутрь try..except в том случае если код внутри catch не требует занятого cs
потому что конструктор Lock тоже теоретически может кинуть исключение
But... If an exception occurs in the Lock ctor(), the object...02.03.10 23:23 Автор: void <Grebnev Valery> Статус: Elderman
> в таком случае - внутрь try..except в том случае если код > внутри catch не требует занятого cs > потому что конструктор Lock тоже теоретически может кинуть > исключение
But... If an exception occurs in the Lock ctor(), the object will be partially created. Will unwinding work for the partially created objects? I mean...if an exception occurs in the Lock ctor(), dtor() (and guard unlock) will not be called. Right?
Исключения в конструкторе - нормальная ситуация и все будет...03.03.10 00:50 Автор: Killer{R} <Dmitry> Статус: Elderman
Исключения в конструкторе - нормальная ситуация и все будет хорошо.
Деструктор же напротив - исключения кидать не должен - все будет плохо.
не все - деструктор для неполностью сконструированного объекта действительно не будет вызван03.03.10 00:58 Автор: dl <Dmitry Leonov> Отредактировано 03.03.10 01:05 Количество правок: 1
И если он выполнял какую-то нетривиальную работу, которую нельзя свести к деструкторам успевших сконструироваться полей объекта, действительно случится проблема.
И похоже, что решение этой проблемы более разумно отнести на более высокий уровень, чем функция, блокировкой которой занимается этот объект - что добавляет еще один плюс в копилку первого варианта :)
Конструктор сам должен быть exception-safe и учитывать возможность бросания исключения в нем самом и освобождать автоматически не освобожаемые ресурсы.
Впрочем у меня давно утвердилась привычка использовать всяческие автохэндлы и прочие scope-guard-like холдеры ресурсов которые устраняют такую проблему как таковую.
это ж как матрешка03.03.10 10:39 Автор: dl <Dmitry Leonov>
> Впрочем у меня давно утвердилась привычка использовать > всяческие автохэндлы и прочие scope-guard-like холдеры > ресурсов которые устраняют такую проблему как таковую.
Только отодвигают - ведь точно так же, как и в случае с этим Lock, теоретически можно допустить возникновение исключения в конструкторах уже этих холдеров. Или в какой-то момент все-таки остановиться и решить - вот в этом простейшем конструкторе исключений точно не будет. В принципе, это же можно отнести и к самому Lock - его функциональность, скорее всего, попадает под определение простейшего.
да нет, это в дебаге было02.03.10 21:49 Автор: dl <Dmitry Leonov> Отредактировано 02.03.10 21:50 Количество правок: 1
Первый вариант выглядит надежнее, поскольку тут ~Lock вызовется после обработчика исключения, во втором варианте - до. Хотя это зависит от поведения обработчика исключения, общается ли он с ресурсом, ради которого проводилась блокировка. Если нет, то по-моему без разницы.