Исправление byko3y, (текущая версия) :
Qt написано без поддержки исключений. Ну вот вообще.
В 1996 году? Да. Я проверил мой QtCreator — собран с исключениями, Q_CHECK_PTR бросает std::bad_alloc при исчерпании памяти. Другое дело, что таки более старая модель у него без исключений — согласен, пример ужасный. Но я же не мог сказать «старый проект на STL» — это было бы что-то максимально абстрактное.
Я подозреваю, что никаких описаний самих этих сложных случаев и примеров возникающих ошибок не будет. Ведь так?
Я подозреваю, что если человек говорит намеками, не утруждаясь высказыванием конкретной позиции, то можно ожидать, что его не поймут.
Конкретные проблемы на самом деле очень легко найти и они почти что лежат в фундаменте сишных библиотек. Например:
https://github.com/gcc-mirror/gcc/blob/9bd194434acb47fac80aad45ed04039e0535d1...
Вопрос: что происходит с еще не удаленными элементами, если в процессе clear() деструктор одного из элементов вызывает функцию с побочными эффектами, которые потенциально обращаются к родительскому std::list, прямо (например, через некую ссылку std::list *owner) или косвенно.
Пример не ограничивается std::list, его можно применить к любому контейнеру STL или просто рукописными взаимным ссылкам — внешне неопределенное состояние во время и после деструкции является нормой для C++. Именно потому, например, автор ZeroMQ отказался от сложных деструкторов в пользу пары init()/term().
Исходная версия byko3y, :
Qt написано без поддержки исключений. Ну вот вообще.
В 1996 году? Да. Я проверил мой QtCreator — собран с исключениями, Q_CHECK_PTR бросает std::bad_alloc при исчерпании памяти. Другое дело, что таки более старая модель у него без исключений — согласен, пример ужасный. Но я же не мог сказать «старый проект на STL?» — это было бы что-то максимально абстрактное.
Я подозреваю, что никаких описаний самих этих сложных случаев и примеров возникающих ошибок не будет. Ведь так?
Я подозреваю, что если человек говорит намеками, не утруждаясь высказыванием конкретной позиции, то можно ожидать, что его не поймут.
Конкретные проблемы на самом деле очень легко найти и они почти что лежат в фундаменте сишных библиотек. Например:
https://github.com/gcc-mirror/gcc/blob/9bd194434acb47fac80aad45ed04039e0535d1...
Вопрос: что происходит с еще не удаленными элементами, если в процессе clear() деструктор одного из элементов вызывает функцию с побочными эффектами, которые потенциально обращаются к родительскому std::list, прямо (например, через некую ссылку std::list *owner) или косвенно.
Пример не ограничивается std::list, его можно применить к любому контейнеру STL или просто рукописными взаимным ссылкам — внешне неопределенное состояние во время и после деструкции является нормой для C++. Именно потому, например, автор ZeroMQ отказался от сложных деструкторов в пользу пары init()/term().