Деструкторы не нужны (?)

гайдлайны в сотни страниц возникают от нежелания включать мозг и проектировать софт перед тем как херачить клешнями по клавиатуре «в «хорошем стиле» на «современном C++»»

exception-safe код писать не просто

Еще раз: exception-safe код прекрасно работает как в присутствии исключений, так и без оных. При его написании нужно думать. Но если кому-то кажется, что без исключений легко написать код с более-менее нормальной очисткой ресурсов и соблюдением инвариантов, то это просто от дурости или недостатка опыта.

Поэтому, много ли ты видел библиотек, которые в API тщательно документировали бы предоставляемую гарантию безопасности исключений?

На практике это не так уж и сильно надо. Базовую гарантию предоставляют практически все качественно сделанные библиотеки. А обеспечение строгой гарантии далеко не всегда возможно. Поэтому если библиотека ее предоставляет, то хорошо, если нет — ну и не страшно.

Тогда уж catch (...)

Неа. От std::exception чуть больше информации в логе будет. (:

И не важно, что там говорят хейтеры: catch (...) всё-таки для (сильно) особых случаев.

гайдлайны в сотни страниц возникают от нежелания включать мозг и проектировать софт перед тем как херачить клешнями по клавиатуре «в «хорошем стиле» на «современном C++»

Зачем ты мне это пишешь? :-) Вот <url=https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md&... в сотни страниц за авторством Страуструпа и Саттера</url> :-) Вот им свой великий комментарий и предъяви :-)

Зачем ты мне это пишешь? :-) Вот гайдлайны в сотни страниц за авторством Страуструпа и Саттера :-) Вот им свой великий комментарий и предъяви :-)

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

Это ты про Qt? :-)

А обеспечение строгой гарантии далеко не всегда возможно. Поэтому если библиотека ее предоставляет, то хорошо, если нет — ну и не страшно.

Если бы ещё библиотекари хотя бы указывали в документации гарантию исключений :-) А то в чужой код с иероглифами на современном C++ лазить - время тратить, поэтому приходится писать свои иероглифы, и тоже тратить время :-) Много времени :-) C++ же, современный же :-)

Чего сказать-то хотели кроме признания в неосиляторстве?

Чего сказать-то хотели кроме признания в неосиляторстве?

Оставь ты эти пацанские фразы для подворотни :-) А сказать я хотел то, что писать по всем канонам на «современном C++» в «хорошем стиле» - дело очень дорогое и часто неблагодарное :-)

А сказать я хотел то, что писать по всем канонам на «современном C++» в «хорошем стиле» - дело очень дорогое и часто неблагодарное :-)

Потому что руководство по хорошему стилю занимает 250 страниц?

никогда не читал их писанину. понапишут херни а своим примером не показывают правильность пути.

потому что дело не в стиле, а в рукожопии!

много страниц назад в этом треде какой-то анон плевался от того, что С++ не дает ему кидать исключения в деструкторе чтоб там «обработать ошибку». это уже признание в рукожопии, потому что мы исходим из того, как мы обрабатываем ошибку. например, транзакция зависла и это надо показать в GUI - добавляем её в какой-нибудь список тупящих, отпускаем ссылку у себя в коде и возвращаемся. дальше задача GUI отображать список, и дать возможность что-то поделать с его элементами, а задача программиста заходить в список и давать пинка повисшим транзакциям.

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

люди в принципе отказываются что-либо проектировать до написания кода, и требуют чтоб им выдали «выразительный» язык чтоб они могли писать произвольный говнокод не приходя в сознание

А сказать я хотел то, что писать по всем канонам на «современном C++» в «хорошем стиле» - дело очень дорогое и часто неблагодарное

На проектах определенного объема и сложности это все равно выгоднее, чем на plain old C в стиле goto cleanup. В коммерческих проектах не бывает таких условий, как у Торвальдса с ядром Linux-а.

Потому что руководство по хорошему стилю занимает 250 страниц?

Потому что следовать им очень трудозатратно :-) «Современный C++» очень большой и продолжает увеличиваться :-) Гайдлайны пытаются предписывать «хороший стиль», чтобы код на таком сложным языке как C++ могли бы читать разные программисты, дабы работать сообща :-) Стандартная библиотека имеет то же назначение :-) И то и другое предназначены для удержания кодеров в пределах подмножества языка, потому что на C++ очень легко написать код, который будет не читаемым ни для кого, кроме автора (который тоже запутается спустя месяц, скорее всего). :-) Т.е. главная цель гайдлайнов - организация совместной работы команды, потому что одиночкам не нужны какие-либо стандарты :-) Готовую команду, которая владеет «современным C++» и которая будет соблюдать гайдлайны на 250 страниц ещё надо поискать, а потом сложить ей цену :-)

PS. Правила Дорожного Движения изложены на 65 страницах в книжечке небольшого формата :-) Их изучают в специальных автошколах и обучение стоит приличных денег :-) И то их умудряются игнорировать и нарушать ежедневно :-) Представь себе теперь ПДД на 250 страниц :-)

Потому что руководство по хорошему стилю занимает 250 страниц?

Потому что следовать им очень трудозатратно :-) «Современный C++» очень большой и продолжает увеличиваться :-) Гайдлайны пытаются предписывать «хороший стиль», чтобы код на таком сложным языке как C++ могли бы читать разные программисты, дабы работать сообща :-) Стандартная библиотека имеет то же назначение :-) И то и другое предназначены для удержания кодеров в пределах подмножества языка, потому что на C++ очень легко написать код, который будет не читаемым ни для кого, кроме автора (который тоже запутается спустя месяц, скорее всего). :-) Т.е. главная цель гайдлайнов - организация совместной работы команды, потому что одиночкам не нужны какие-либо стандарты :-) Готовую команду, которая владеет «современным C++» и которая будет соблюдать гайдлайны на 250 страниц ещё надо поискать, а потом сложить ей цену :-)

PS. Правила Дорожного Движения изложены на 65 страницах в книжечке небольшого формата :-) Их изучают в специальных автошколах и обучение стоит приличных денег :-) И то их умудряются игнорировать и нарушать ежедневно :-) Представь себе теперь ПДД на 250 страниц :-)

Все правильно сказал. я это даже в копипасту утащу.

Потому что руководство по хорошему стилю занимает 250 страниц?

Потому что следовать им очень трудозатратно :-)

Это ерунда. По суммарным трудозатратам следовать им проще, чем старым.

Правила Дорожного Движения изложены на 65 страницах в книжечке небольшого формата :-) Их изучают в специальных автошколах и обучение стоит приличных денег :-)

Какое дешевое передергивание.

На проектах определенного объема и сложности это все равно выгоднее, чем на plain old C в стиле goto cleanup.

Чем больше команда, тем сложнее контролировать её в соблюдении правил «хорошего стиля» :-) Поэтому, чем больше команда, тем проще должны быть правила, тем проще должен быть язык :-)

В коммерческих проектах не бывает таких условий, как у Торвальдса с ядром Linux-а.

Да уж, команда у него большая, а язык - всё тот же C :-)

Это ерунда. По суммарным трудозатратам следовать им проще, чем старым.

Чем ты подкрепишь сие утверждение? :-)

Какое дешевое передергивание.

Это факт из реальности :-) Если тебе не нравится сравнение с ПДД, пожалуйста, давай сравним с JPL или даже с MISRA :-)

По суммарным трудозатратам следовать им проще, чем старым.

Чем ты подкрепишь сие утверждение? :-)

Опытом, естественно. Но просто для протокола: у меня нет цели убедить тебя в чем-то, поэтому мне безразлично, является ли мой опыт убедительным для тебя.

Это факт из реальности :-)

В реальности автошколы учат водить машину, а изучение правил - малая часть этого. Так что да - дешевое передергивание.

Шла двадцатая страница, а лор-овцы продолжали кормить жирного смайлодауна...

Разговор был лишь о том, что в c++ наследование от stl клссов черевато выстрелом в ногу из гранатомета.

с чего бы?

В c# никто не мешает тебе добавить эктеншен-методы, или внешние классы для сеарилизации любого типа.

что мешает тоже самое в С++ сделать?

с чего бы?

Наверное потому что деструкторы не виртуальные?

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

Просвети, каким же образом этого можно добиться устойчивости к изменениям в рамках процедурного программирования. А то на сраной земляшке для этого ООП выдумали.

Это ты про Qt? :-)

Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there.

Если исключение вылетит в обработчике события, то не вполне удобно будет его ловить.

И да, Qt показывает, насколько бывает непросто «с более-менее нормальной очисткой ресурсов и соблюдением инвариантов» но без исключений.

Просвети, каким же образом этого можно добиться устойчивости к изменениям в рамках процедурного программирования. А то на сраной земляшке для этого ООП выдумали.

Пришелец из параллельной Вселенной спалился.

И да, Qt показывает, насколько бывает непросто «с более-менее нормальной очисткой ресурсов и соблюдением инвариантов» но без исключений.

Зарабатывать деньги и приносить при этом пользу вообще бывает непросто :-) И это вообще никак не зависит от того, используются ли какие-то там деструкторы или нет :-)