Можно ли гарантировать порядок деструктора, когда объекты будут объявлены на стеке?
если Вы использовали:
jQuery.fn.exists = function(){return ($(this).length > 0);}
if ($(selector).exists()) { }
Вы подразумевали бы, что объединение в цепочку было возможно, когда это не.
Это было бы лучше
jQuery.exists = function(selector) {return ($(selector).length > 0);}
if ($.exists(selector)) { }
4 ответа
Да, это так. В любой конкретной области действия локальные объекты уничтожаются в порядке, обратном их созданию.
Да, деструкторы вызываются в обратном порядке построения.
Дополнение к ответу Нила.
Подумайте, верно ли обратное, то есть вы не можете предсказать порядок деструкторов для объявленного стека переменные. Это сделало бы почти невозможным использование зависимых типов значений в стеке. Рассмотрим
void Foo() {
Type1 t1;
Type2 t2(&t1);
...
}
. Если бы C ++ не гарантировал порядок деструкторов, такой прямой код был бы невероятно небезопасным, потому что t1 мог бы быть уничтожен до запуска деструктора t2. Следовательно, вы не можете гарантировать, что деструктор t2 работал с допустимым значением t1.
На вопрос уже был дан ответ, но я ' Хочу добавить, что обычно у меня есть привычка писать что-то вроде этого:
void PerformLogin()
{
ScopeLock < Lock > LoginLock( &m_LoginLock );
doLoginCommand();
{
ScopeLock < SharedMemoryBase > MemoryLock( &m_SharedMemory );
doStoreLogin();
...
}
}
На мой взгляд, это проясняет намерение (*). Это может быть актуально, если ваш код действительно полагается на определенный порядок. Я считаю, что это снижает вероятность того, что кто-то случайно изменит порядок, и вызывает труднодоступную ошибку. (Ну, это, конечно, не проблема, поскольку у всех есть тесты, не разве мы?)
Я всегда пишу лишние скобки в чем-то вроде (a && b) || c тоже, и я считаю этот вопрос очень похожим.
(*): Конечно, вы также можете использовать комментарий.