По хорошему, подобная информация является основанием для возбуждения уголовного дела против АО «Телега» и это не только из-за неправомерного доступа к компьютерной информации, но и за нарушение закона о рекламе и наверно еще ЗЗПП.
C++ в принципе не может идти по пути Ада, потому что для Ада сперва создавались согласованные требования и только после этого разрабатывался язык и его синтаксис, тогда как в С++ все с точностью наоборот. Сперва сделали С с классами для реализации ограниченного набора идей, а уже после начали на него наворачивать новые концепции, пытаясь их встроить в уже существующий синтаксис.
Если у вас в коде есть ошибка, которую вы не знаете как обработать - кидать исключение - самая глупая идея, которая только может придти вам в голову. Самое разумное в этом случае: немедленно завершить процесс …
Как по мне, так самое глупое, что может сделать программист отдельного компонента (функции, метода или библиотеки), это завершать работу всего приложение, если не знает как обработать в данный момент ошибочную ситуацию.
Использование исключений обязано определяться требованиями, а никак не личными предпочтениями разработчика или его пониманием (или не пониманием) обработки данных.
Я думаю, что он не загнется (ведь ассемблеры существуют до сих пор?). Просто в будущем он займет примерно такую же роль, как сейчас LLVM для генерации машинного кода. Супер универсальный высокоуровневый язык программирования без накладных расходов, но писать на нем вручную можно будет только либо отдельные небольшие фрагменты, либо полностью автоматически генерированный код.
У вас класс принимает бизнес данные в конструктор, а это особенный вызов, который физически не может вернуть информацию об ошибке никаким другим способом, кроме как вызвать исключение.
Делайте или статический фабричный метод или проверяйте данные не в конструкторе, а с помощью обычной функции. Другими словами, прерывания тут совершено не причем.
Данная фраза относится к архитектурным требованиям, которые я считаю разумными. Но вы можете использовать исключения в каких нибудь других вариантах использования. Ведь это обычный инструмент, и как его применять, только ваше дело.
… вот против того, чтобы использовать исключения в качестве механизма возврата любой ошибки, даже не блокирующей, которую надо просто зафиксировать и идти дальше.
Так именно это я и имею ввиду. Исключения нельзя использовать для обработки часто возникающих ситуаций. Их назначение - прерывать поток выполнения при возникновении не восстановимой ситуации, когда становится не важна производительность и требуется корректно обработать завершение приложения. Но если на более высоком уровне есть механизм обработки подобных ситуаций, то пусть он перехватывает исключения и продолжает работу приложения дальше (например вот так Избавляемся от ошибок Segmentation fault из-за переполнения стека в С++).
Другими словами, исключение, это не обработчик ошибок, а возникновение события достаточного для завершения работы всего приложения, но с возможностью его обработки на более высоких уровнях.
К тому же у вас всегда остается возможность просто не перехватывайте исключения. Тогда приложение будет сразу завершаться, что будет полностью соответствовать поведению Rust.
Я не требую использовать исключения в качестве единственного варианта обработки ошибок. Я пишу про то, что в определенных случаях исключения очень удобны, а прерывание выполнения потока команд так или иначе присутствует во всех языках программирования, даже в тех, у которых исключения якобы отсутствуют.
Поэтому лучше иметь стандартизированные исключения с возможностью их обработки в рантайме, чем в каждом случае завершать выполнение приложения по abort или с помощью хаков пытаться реализовывать перехват подобных ошибок.
И каждого варианта свои стандарты, свои компиляторы, возможно свои особенности синтаксиса … И все это должно иметь возможность взаимодействия между сбой. Как представлю, бррр… :-(
Комитет должен отойти от практики публикации опережающих реальность спецификаций. Вместо того, чтобы декларировать свои фантазии …
Мне кажется, что в С++26 включили рефлексию и контракты, просто чтобы снизить градус критики комитета. Как будто подкинули пару задач на ближайшие три года, чтобы не заниматься безопасностью и действительно важными вещами.
Я не хочу сказать, что рефлексию и контракты вещи “не важные”. Важные, вот только статическая рефлексия типов в текущем виде напрашивалась пару десятилетий назад, а контракты предложены в кокой-то непонятной (для меня) форме.
Было бы понятно, если бы контракты были аналогичны реализованным в Ада как элемент доказательно программирования во время компиляции для сужения значений у типов данных. Но если я правильно понял, принятый в С++26 вариант контрактов не вводит сужения значений для типов, а реализует обычные проверки условий, в том числе и в рантайм, что делает их обычной комбинацией static_assert и обычного assert. И стоило из-за этого городить огород?
На мой взгляд, одна из ключевых и пока что нерешенных проблем C++ в том, что в огромном количестве проектов исключения под запретом. Да, идея была крутой для конца 1980-х, однако испытания реальностью не выдержала.
Мне кажется, что исключения так и остаются самой крутой штукой С++ и выдержали испытания, так как их функционал присутствует во всех языках программирования, даже тех, кто от них якобы отказалася.
Но сложности с их использования действительно есть, но как правило это не проблема С++ как такового, а проблема интерфейса между компонентами, ведь extern “C” ничего не знает об исключениях. Поэтому не помешал бы какой нибудь дополнительный механизм их проброса исключений через интерфейсы.
Типа в начале .cpp-файла указывается версия С++, для которой в этом файле пишется код. Но, к сожалению, эту идею в комитете похоронили.
Идея привязки кода к разным версиям стандарта существует до сих пор и частично прорабатывается в профилях безопасности. Просто это привязка реализуется не к нумерации стандарта С++, а к его возможностям, которые не связанных одной версией, что гораздо более правильно, как мне кажется.
то, что есть в тех компиляторах, которыми приходится пользоваться. Собственно, это и есть реальный С++. …
На самом деле скорее всего есть четыре, а не три типа С++. Четвертый вид С++идет идет следующим и называется “то, что реально пользуются в продакшене”. Обычно это возможности, которые отстают от третьего пункта на несколько поколений стандарта. Возможности, у кого известны все подводные камни и нюансы и есть наработана легаси практика.
А, нет. Есть еще и пяты тип С++ - это весь объем легаси кода, который тянет за собой обязательное требование по обратной совместимости со самыми старыми версиями и именно этоот пятый вид и тормозит развитие С++.
Он позволил реализовать полную рефлексию в ROOT (я один из соавторов). Одно условие, все классы наследовались от TObject.
Статическая рефлексия и рефлексия в рантайм, это не одно и тоже. И если речь идет о рефлексии в рантайме, то совершено правильно, что Страустрап на это не пошел.
Герб Саттер когда-то анонсировал свой cpp2, который превратился в C++26, в котором Будет Усе… и reflection и memory safety.
А оригинальный Телеграм и не нужен, тут достаточно пользователя и АО «Телега»
По хорошему, подобная информация является основанием для возбуждения уголовного дела против АО «Телега» и это не только из-за неправомерного доступа к компьютерной информации, но и за нарушение закона о рекламе и наверно еще ЗЗПП.
C++ в принципе не может идти по пути Ада, потому что для Ада сперва создавались согласованные требования и только после этого разрабатывался язык и его синтаксис, тогда как в С++ все с точностью наоборот. Сперва сделали С с классами для реализации ограниченного набора идей, а уже после начали на него наворачивать новые концепции, пытаясь их встроить в уже существующий синтаксис.
Как по мне, так самое глупое, что может сделать программист отдельного компонента (функции, метода или библиотеки), это завершать работу всего приложение, если не знает как обработать в данный момент ошибочную ситуацию.
Использование исключений обязано определяться требованиями, а никак не личными предпочтениями разработчика или его пониманием (или не пониманием) обработки данных.
Вам уже написал, что это вы ССЗБ и нечего пенять на молоток при кривых руках.
Я думаю, что он не загнется (ведь ассемблеры существуют до сих пор?). Просто в будущем он займет примерно такую же роль, как сейчас LLVM для генерации машинного кода. Супер универсальный высокоуровневый язык программирования без накладных расходов, но писать на нем вручную можно будет только либо отдельные небольшие фрагменты, либо полностью автоматически генерированный код.
У вас класс принимает бизнес данные в конструктор, а это особенный вызов, который физически не может вернуть информацию об ошибке никаким другим способом, кроме как вызвать исключение.
Делайте или статический фабричный метод или проверяйте данные не в конструкторе, а с помощью обычной функции. Другими словами, прерывания тут совершено не причем.
Данная фраза относится к архитектурным требованиям, которые я считаю разумными. Но вы можете использовать исключения в каких нибудь других вариантах использования. Ведь это обычный инструмент, и как его применять, только ваше дело.
Так именно это я и имею ввиду. Исключения нельзя использовать для обработки часто возникающих ситуаций. Их назначение - прерывать поток выполнения при возникновении не восстановимой ситуации, когда становится не важна производительность и требуется корректно обработать завершение приложения. Но если на более высоком уровне есть механизм обработки подобных ситуаций, то пусть он перехватывает исключения и продолжает работу приложения дальше (например вот так Избавляемся от ошибок Segmentation fault из-за переполнения стека в С++).
Другими словами, исключение, это не обработчик ошибок, а возникновение события достаточного для завершения работы всего приложения, но с возможностью его обработки на более высоких уровнях.
std::set_terminate ?
Вы не ответили на заданный вопрос.
К тому же у вас всегда остается возможность просто не перехватывайте исключения. Тогда приложение будет сразу завершаться, что будет полностью соответствовать поведению Rust.
Иииии…?
Я не требую использовать исключения в качестве единственного варианта обработки ошибок. Я пишу про то, что в определенных случаях исключения очень удобны, а прерывание выполнения потока команд так или иначе присутствует во всех языках программирования, даже в тех, у которых исключения якобы отсутствуют.
Поэтому лучше иметь стандартизированные исключения с возможностью их обработки в рантайме, чем в каждом случае завершать выполнение приложения по abort или с помощью хаков пытаться реализовывать перехват подобных ошибок.
И каждого варианта свои стандарты, свои компиляторы, возможно свои особенности синтаксиса … И все это должно иметь возможность взаимодействия между сбой. Как представлю, бррр… :-(
А кто вам мешает именно в этом месте сделать другой способ обработки ошибок, например на возвращаемых значениях?
Мне кажется, что в С++26 включили рефлексию и контракты, просто чтобы снизить градус критики комитета. Как будто подкинули пару задач на ближайшие три года, чтобы не заниматься безопасностью и действительно важными вещами.
Я не хочу сказать, что рефлексию и контракты вещи “не важные”. Важные, вот только статическая рефлексия типов в текущем виде напрашивалась пару десятилетий назад, а контракты предложены в кокой-то непонятной (для меня) форме.
Было бы понятно, если бы контракты были аналогичны реализованным в Ада как элемент доказательно программирования во время компиляции для сужения значений у типов данных. Но если я правильно понял, принятый в С++26 вариант контрактов не вводит сужения значений для типов, а реализует обычные проверки условий, в том числе и в рантайм, что делает их обычной комбинацией static_assert и обычного assert. И стоило из-за этого городить огород?
Мне кажется, что исключения так и остаются самой крутой штукой С++ и выдержали испытания, так как их функционал присутствует во всех языках программирования, даже тех, кто от них якобы отказалася.
Но сложности с их использования действительно есть, но как правило это не проблема С++ как такового, а проблема интерфейса между компонентами, ведь extern “C” ничего не знает об исключениях. Поэтому не помешал бы какой нибудь дополнительный механизм их проброса исключений через интерфейсы.
Идея привязки кода к разным версиям стандарта существует до сих пор и частично прорабатывается в профилях безопасности. Просто это привязка реализуется не к нумерации стандарта С++, а к его возможностям, которые не связанных одной версией, что гораздо более правильно, как мне кажется.
На самом деле скорее всего есть четыре, а не три типа С++. Четвертый вид С++идет идет следующим и называется “то, что реально пользуются в продакшене”. Обычно это возможности, которые отстают от третьего пункта на несколько поколений стандарта. Возможности, у кого известны все подводные камни и нюансы и есть наработана легаси практика.
А, нет. Есть еще и пяты тип С++ - это весь объем легаси кода, который тянет за собой обязательное требование по обратной совместимости со самыми старыми версиями и именно этоот пятый вид и тормозит развитие С++.
Рефлексия может быть в рантайм (получить информацию о классе во время выполнения программы) и может быть статическая, т.е. только во время компиляции.
В С++ рефлексия статическая без рантайм оверхеда, который неизбежен в случае наследования всех классов от TObject.
Статическая рефлексия и рефлексия в рантайм, это не одно и тоже. И если речь идет о рефлексии в рантайме, то совершено правильно, что Страустрап на это не пошел.
Герб Саттер не позиционировал свой проект, как замена С++, тем более с reflection и memory safety. In short, it aims to help evolve C++ itself, not to be a “C++ successor.”.
Так это проблема, что программист не проверяет указатель на недействительность, а не самого nullptr.
Можно принудительно кастануть Option, когда там нет инициализировнного указателя и тоже будет ошибка, но ведь это не становится проблемой Option?