Delphi и его диалект в FPC - прекрасные языки, причем достаточно современные. Все эти годы он не топтался на месте: добавили языковые фишки вроде неймспейсинга, дженериков, анонимных функций
К сожалению в результате многолетнего наслоения правок, сам язык иногда выглядит странно. Моя любимая фишка: array of T в описании переменной и параметра функции значит совершенно разное. Есть нормальные типы, а есть managed, которые ведут себя по разному. И есть случаи, где dynarray ведет себя третьим образом :)
Borland сами выстрелили себе в ногу, выпустив на замену дешевому Turbo Pascal дорогую среду с ориентацией на базы данных. Не догадывались, как это отразится на популярности? Ну и качество кодогенерации застряло в прошлом веке, что не помогало в конкуренции
И кто же мешает в гипотетическом случае разрешения С++ в ядре запретить исключения директивно? Как сейчас запрещены свежие стандарты С и разрешены гнушные расширения
когда вы, или стандартная библиотека для вас в вашем коде бросаете исключение - вы ответственны за его обработку и должны знать где его будут ловить. Никто не мешает поймать и наверх передать уже код ошибки.
В отличие от языка C, который полагается на возвращаемые значения для индикации ошибок, C++ поощряет использование исключений. Однако, исключения могут возникать в любой части кода, что делает код, генерирующий их, в некоторой степени непредсказуемым.
C++ отлично умеет работать без исключений, если хочется. пример: Chrome. нет никакой "непредсказуемости". Исключения возникают только там, где кто-то написал throw
К сожалению в результате многолетнего наслоения правок, сам язык иногда выглядит странно. Моя любимая фишка: array of T в описании переменной и параметра функции значит совершенно разное. Есть нормальные типы, а есть managed, которые ведут себя по разному. И есть случаи, где dynarray ведет себя третьим образом :)
Borland сами выстрелили себе в ногу, выпустив на замену дешевому Turbo Pascal дорогую среду с ориентацией на базы данных. Не догадывались, как это отразится на популярности? Ну и качество кодогенерации застряло в прошлом веке, что не помогало в конкуренции
И кто же мешает в гипотетическом случае разрешения С++ в ядре запретить исключения директивно? Как сейчас запрещены свежие стандарты С и разрешены гнушные расширения
оно точно так же должно собираться и работать без них. Где проблема?
когда вы, или стандартная библиотека для вас в вашем коде бросаете исключение - вы ответственны за его обработку и должны знать где его будут ловить. Никто не мешает поймать и наверх передать уже код ошибки.
Гарантия очень простая - ловите сами и наверх ничего не уйдет.
так это хорошо, программа упадет на первом же тесте и придется добавить catch
то есть вы утверждаете, что стандарт С++ требует наличия throw/catch в коде? 😏
C++ отлично умеет работать без исключений, если хочется. пример: Chrome. нет никакой "непредсказуемости". Исключения возникают только там, где кто-то написал throw
Куда запускается? нет фабрики, которая это согласится делать
Потому что в стандарте в [dcl.array] написано про непрерывность
Многомерные массивы ГАРАНТИРОВАННО лежат в памяти последовательно. Проблемы лежат исключительно в области гарантий языка.
прямо так модулей в стандарте нет? (не будем пока о том, как оно работает)
Не "тип определяется", а "тип выводится автоматически". Что очень неплохо для шаблонов
https://dlang.org/
На D смотришь как на скелет динозавра 😏
Лично вы пытались что-то стандартизировать? Думаете достаточно решить и оно само сделается? и 25 конкурирующих предложений исчезнут?
OS/2 2.0 вышла в 92, Windows NT вышла в 93
ну я как-то пока обхожусь без С++ библиотек, никто не мешает звать BLAS напрямую 😏
проверка индексов по умолчанию - сомнительное решение. Лучше наоборот, как сделано в std::vector
C++23 на дворе, где поддержка subscript opеrator с несколькими индексами?