Как избежать использования разрушенной переменной?

Никак не могу найти приемлимое решение следующей проблемы.

Допустим, мы имеем логирующую функцию log(), которая может быть вызвана из любого места программы. Например:

Проблема в том, что второй по времени вызов log(), который произойдёт из ~A(), приведёт к неопределённому поведению или крашу, так как статическая переменная "m" уже разрушена. Как выходить из таких ситуаций?

Вижу следующие варианты, которые мне не совсем нравятся:
* Не создавать в деструкторах зависимость от других глобальных переменных. В данном примере - не вызывать log() из ~A(). Но ведь можно представить ситуацию, что в деструкторе ожидается завершение параллельного потока, который как раз может использовать log()...
* Переместить в самый верх кода подобные глобальные переменные, делая их последними в очереди на разрушение. В данном примере - переместить "m" наверх. Но тогда реализация функции log() будет разделена на 2 части...

0

Сообщение от Paket236 Но ведь можно представить ситуацию, что в деструкторе ожидается завершение параллельного потока, который как раз может использовать log()

Потоки должны завершиться до return. Разве нет?

0

Сообщение от Paket236 так как статическая переменная "m" уже разрушена.

с чего вдруг?

Добавлено через 1 минуту

Сообщение от Paket236 static std::shared_ptr<std::mutex> m = std::make_shared<std::mutex>();

а зачем мутекс делать шаред?

0

Сообщение от Paket236 Переместить в самый верх кода подобные глобальные переменные, делая их последними в очереди на разрушение. В данном примере - переместить "m" наверх. Но тогда реализация функции log() будет разделена на 2 части...

Это ничего не даст, если в проекте появятся глобальные объекты в разных файлах. Порядок создания и уничтожения объектов в разных ЕТ не определен.

Сообщение от Paket236 Не создавать в деструкторах зависимость от других глобальных переменных. В данном примере - не вызывать log() из ~A(). Но ведь можно представить ситуацию, что в деструкторе ожидается завершение параллельного потока, который как раз может использовать log()...

Тут скорее нужно избавляться от самих глобальных переменных.

0

DrOffset, а конкретно в его случае static в функции когда уничтожается? Просто в общем порядке обявления с этими a, b? Это вообще как-то регламентировано?

0

Сообщение от nmcf Это вообще как-то регламентировано?

Регламентировано в пределах одной ЕТ.

Сообщение от nmcf DrOffset, а конкретно в его случае static в функции когда уничтожается?

Уничтожается в порядке, обратном созданию.

У него в коде сначала будет создание объекта a, затем посредством вызова функции создастся локальный статический объект m, потом объект b.

Добавлено через 10 минут
Не смотря на то, что ТС скорее всего это не понравится, единственное нормальное решение здесь - это избавляться от глобальных объектов совсем, если в их деструкторах предполагается такая сложная взаимологика.

1

DrOffset, с созданием понятно, а уничтожение? Не очевидно, что это зависит от положения функции в файле.

0

Сообщение от nmcf с созданием понятно, а уничтожение? Не очевидно, что это зависит от положения функции в файле.

Я же написал

Сообщение от DrOffset Уничтожается в порядке, обратном созданию.

Добавлено через 2 минуты

Сообщение от nmcf Не очевидно, что это зависит от положения функции в файле.

Не от положения функций, а от порядка создания.
Порядок создания глобальных объектов зависит от порядка их объявления в файле. А локальный статический объект создается в момент первого обращения. Если вы написали такой код, который вклинивает первое обращение между созданием двух глобальных объектов, ну что ж, значит так тому и быть: уничтожение будет в порядке обратном созданию. Потому что у всех этих объектов один и тот же storage duration.

1

Сообщение от nmcf Потоки должны завершиться до return. Разве нет?

Тоже так думал раньше... Но нигде не находил подтверждение данному предположению, везде подразумевались деструкторы для завершения потоков. Да, завершение потоков "до return" упрощает решение некоторых проблем, но одна из них воспроизводится в том числе и в однопотоке и описана она в первом посте... Поэтому я засомневался.

Сообщение от Алексей1153 с чего вдруг?

Если пройтись пошагово в отладчике Visual Studio 2019, то это видно.

Сообщение от Алексей1153 а зачем мутекс делать шаред?

Как раз для того, чтобы это было видно и можно было воспроизвести краш.

Сообщение от DrOffset Тут скорее нужно избавляться от самих глобальных переменных.

На самом деле, можно провести аналогию не с глобальными переменными, а с полями класса. Хотя, здесь, кажется, придумать что-то можно. Например, заменить тип проблемного поля на std::shared_ptr и скопировать его туда, где оно может использоваться во время разрушения полей (например, в параллельный поток, который должен завершиться в одном из деструкторов одного из полей), тем самым продлив жизнь данным.

Сообщение от DrOffset У него в коде сначала будет создание объекта a, затем посредством вызова функции создастся локальный статический объект m, потом объект b.

Да, так и есть.

Сообщение от DrOffset Не смотря на то, что ТС скорее всего это не понравится, единственное нормальное решение здесь - это избавляться от глобальных объектов совсем, если в их деструкторах предполагается такая сложная взаимологика.

Тогда буду думать в этом направлении. Спасибо за совет! Если других предложений не будет, то помечу данный пост как решение.

0

Сообщение от Paket236 Если пройтись пошагово в отладчике Visual Studio 2019, то это видно.

да, я уже понял, почему это возможно. Из ответе № 8 Но это нужно постараться

0

Сообщение от Paket236 Если других предложений не будет

Paket236, есть решение, правда оно зависит от вариантов использования. Это решение описано в книге Александреску "Современное проектирование на C++". Называется синглтон "Феникс".
Его суть в том, что объект может быть уничтожен, но синглтон написан так, что "возрождает" его, если происходит обращение к "трупу" .
Для вашего класса "логгер" может подойти, но если требуется сохранять состояние от одной жизни к другой, то могут возникнуть сложности.

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

1

Вроде бы нашёл в разделе Termination. Витиевато написано.

If the completion of the constructor or dynamic initialization of an object with static storage duration strongly happens before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first. If the completion of the constructor or dynamic initialization of an object with thread storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first.

Добавлено через 3 минуты

0

Кажется, нашёл приемлемое решение.
Проблема описана здесь (не уверен, разрешены ли здесь ссылки на сторонние ресурсы):
1: How do I prevent the "static initialization order problem".
2: Why doesn’t the Construct On First Use Idiom use a static object instead of a static pointer?.

Смысл следующий. Чтобы контролировать порядок создания глобальной переменной, нужно обернуть её в функцию, дописать static (как это сделано в функции log() в моём примере) и вызвать в нужном месте. А чтобы гарантировать неразрушенность этой переменной в каком-нибудь "глобальном" деструкторе, нужно сделать пробный "создающий" вызов в соответствующем конструкторе. Таким образом, мой пример станет выглядеть вот так (изменилась лишь строка #8):

Если бы можно было все "создающие" вызовы (такие, как log()) разместить в каком-нибудь callback'е и передать его в OS-зависимую функцию, которая вызовет этот callback до main() и до создания всех глобальных переменных, было бы ещё лучше. Но я ничего такого при беглом гуглении не нашёл.

0

Сообщение от Paket236 Кажется, нашёл приемлемое решение.

Ну то есть хорошее решение вам не нужно, нужно просто хоть какое-то?

Как я уже сказал, это решение не будет гарантированно работать, если глобальные объекты, использующие эту функцию, находятся в разных ЕТ. Т.е. в пределах одного файла ваше решение сработает, если файлов несколько - не факт.

Да, там по вашей ссылке есть еще один вариант решения: паттерн Nifty Counter, но вы что-то про него не сказали ничего, и ваш пример решением проблемы в целом не является.

0

Сообщение от DrOffset Как я уже сказал, это решение не будет гарантированно работать, если глобальные объекты, использующие эту функцию, находятся в разных ЕТ. Т.е. в пределах одного файла ваше решение сработает, если файлов несколько - не факт.

Я сначала не хотел спорить и остаться при своём... но всё же решил уточнить.
Можно как-то убедиться в этом утверждении? Потому как я не увидел где-то упоминаний (например, читая здесь и здесь), что данное решение может иметь проблемы при использовании разных единиц трансляции. Плюс, моя собственная проверка пока не подтвердила это.

0

Сообщение от Paket236 Как выходить из таких ситуаций?

Разрушение статических объектов происходит в обратном порядке по отношению к их созданию.
Соответственно, правило: если деструктор хочет позвать статический объект, тогда в конструкторе тоже нужно позвать этот же самый статический объект.

Сообщение от Paket236 static std::shared_ptr<std::mutex> m = std::make_shared<std::mutex>();

В вашем случае используется локальный статический объект.
Локальные статические объекты имеют иммунитет к "неопределенному порядку инициализации единиц трансляций"

Проблема тут может быть только в том случае, если два статических объекта перекрестно ссылаются друг на друга в конструкторах.
Но так как ваша функция log никак не зависит от класса A, то проблем никаких.

Сообщение от DrOffset Как я уже сказал, это решение не будет гарантированно работать

Будет.

Пока конструктор полностью не завершил свою работу, объект считается ещё не созданным.
В момент работы конструктора объекта класса A

Сообщение от Paket236 A() { log(""); }        // фикс

Вызов log("") происходит в момент, когда объект A ещё не построен.
Поэтому, локальный статический объект, принадлежащий функции log, гарантированно будет создан раньше, чем объект класса A

А дальше вступает в силу:

Сообщение от DrOffset Уничтожается в порядке, обратном созданию.

На момент работы деструктора объекта класса A, локальный статический объект функции log ещё жив, потому что он был создан раньше, чем был создан объект класса А, и следовательно гарантированно проживет дольше, чем объект класса A

2

Сообщение от Paket236 Можно как-то убедиться в этом утверждении?

Вот здесь в конце об этом говорится: https://isocpp.org/wiki/faq/ct... rst-use-v2

Суть проблемы не в порядке статической инициализации (ее вы как раз победили, разместив вызов в конструкторе, и выкладки автора выше в этом вопросе верны), а в статической деинициализации.
Эту проблему как раз решают паттерны "Nifty counter" и "Phoenix singleton".

Paket236, оратор выше в целом отвечал не на то, о чем я говорил.

Вот у вас есть три объекта в текущей ЕТ - а, b, c, объявленные друг за другом. Все они используют log в своих деструкторах. Вы смотрите, что объект А идет первым, поэтому добавляете туда (по вашему посту №13) "создающий вызов". Далее есть другая ЕТ, где объекты идут в другом составе, например, как b, c. Тогда и в конструктор B нужно тоже будет добавить такой создающий вызов. Если этого не сделать, не смотря на то, что есть ЕТ, где порядок верный, может случиться "фиаско", но уже в деструкторе B.
Т.е. таким образом абсолютно любой такой глобальный объект, где бы он не находился, должен делать такие создающие вызовы в конструкторе, что в общем-то достаточно неудобно, и требует постоянного контроля за новыми такими объектами в разных ЕТ.
Поэтому я и говорю, что это решение не будет гарантированно работать из-за особенностей компиляции C++ и присутствия человеческого фактора.

1

Вообще-то тут есть один момент, на который программисты больших компьютеров не обращают внимания:
Да, статический неконстантный объект внутри функции log создается в момент первого вызова функции. Но какой ценой это реализовано? А реализовано это в общем случае довольно просто: есть скрытый статический флаг "объект m создан", который инициализируется значением false перед вызовом конструкторов. Далее, при каждом вызове функции происходит проверка: а не равен ли этот флаг false и если равен - вызывается конструктор объекта и флаг переводится в состояние true. То есть действие, которое нужно сделать всего один раз тянет за собой код, который делает бесполезную работу при каждом вызове этой функции в течении всего остального времени жизни программы. Ну, и еще этот скрытый флаг занимает память.

Не считая страдания моего чувства прекрасного можно сделать такой вывод: в функции, которая в ходе выполнения программы вызывается очень часто использование локальных нестатических объектов ведет к снижению производительности.

Ну и это все относится также и к шаблону проектирования singleton, поскольку в нем точно такой же механизм реализован вручную.

1

Dushevny, начиная с С++11 этот флаг еще и атомарным обязан быть, что не добавляет к упомянутому производительности

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

0

DrOffset, спасибо за разъяснения, теперь понял вашу мысль. Я это подразумевал уже на тот момент, так что готов с этим смириться. Придётся теперь это учитывать.

eva2326, Dushevny, тоже поставил плюсы за ваши комментарии.

0