Delphi и его диалект в FPC - прекрасные языки, причем достаточно современные. Все эти годы он не топтался на месте: добавили языковые фишки вроде неймспейсинга, дженериков, анонимных функций
К сожалению в результате многолетнего наслоения правок, сам язык иногда выглядит странно. Моя любимая фишка: array of T в описании переменной и параметра функции значит совершенно разное. Есть нормальные типы, а есть managed, которые ведут себя по разному. И есть случаи, где dynarray ведет себя третьим образом :)
Borland сами выстрелили себе в ногу, выпустив на замену дешевому Turbo Pascal дорогую среду с ориентацией на базы данных. Не догадывались, как это отразится на популярности? Ну и качество кодогенерации застряло в прошлом веке, что не помогало в конкуренции
И кто же мешает в гипотетическом случае разрешения С++ в ядре запретить исключения директивно? Как сейчас запрещены свежие стандарты С и разрешены гнушные расширения
когда вы, или стандартная библиотека для вас в вашем коде бросаете исключение - вы ответственны за его обработку и должны знать где его будут ловить. Никто не мешает поймать и наверх передать уже код ошибки.
В отличие от языка C, который полагается на возвращаемые значения для индикации ошибок, C++ поощряет использование исключений. Однако, исключения могут возникать в любой части кода, что делает код, генерирующий их, в некоторой степени непредсказуемым.
C++ отлично умеет работать без исключений, если хочется. пример: Chrome. нет никакой "непредсказуемости". Исключения возникают только там, где кто-то написал throw
Какая именно стандартная библиотека? ну и сравнение с интеловской векторной функцией не помешало бы
С чего бы это? нормальные компиляторы Fortran компилируют без всякого C
Мерить скорость языков надо на хорошем коде
тут реализация наивная, без блоков. До кучи еще ненужное обращениее к памяти потому что double**
Потому что они не нужны. программная реализация на SSE2 etc. быстрее того, что в x87 зашито.
VMT никто не инициализирует, оно тупо упадет на первом же виртуальном вызове
Это не проблема, не надо слушать таких. ООП это всего лишь инструмент, он не обязан решать все задачи.
fp умножение, о котором идет речь, запускается 2 штуки в параллель каждый такт.
в минимальной реализации у вас даже знак не учитывается. на современном x86 процессоре умножение занимает 3 такта.
Быстрое? где тесты?
Тут есть забавный идиотизм со стороны Embarcadero: community edition обычно не самая последняя версия. но это точно лучше чем искать старую :)
К сожалению в результате многолетнего наслоения правок, сам язык иногда выглядит странно. Моя любимая фишка: array of T в описании переменной и параметра функции значит совершенно разное. Есть нормальные типы, а есть managed, которые ведут себя по разному. И есть случаи, где dynarray ведет себя третьим образом :)
Borland сами выстрелили себе в ногу, выпустив на замену дешевому Turbo Pascal дорогую среду с ориентацией на базы данных. Не догадывались, как это отразится на популярности? Ну и качество кодогенерации застряло в прошлом веке, что не помогало в конкуренции
И кто же мешает в гипотетическом случае разрешения С++ в ядре запретить исключения директивно? Как сейчас запрещены свежие стандарты С и разрешены гнушные расширения
оно точно так же должно собираться и работать без них. Где проблема?
когда вы, или стандартная библиотека для вас в вашем коде бросаете исключение - вы ответственны за его обработку и должны знать где его будут ловить. Никто не мешает поймать и наверх передать уже код ошибки.
Гарантия очень простая - ловите сами и наверх ничего не уйдет.
так это хорошо, программа упадет на первом же тесте и придется добавить catch
то есть вы утверждаете, что стандарт С++ требует наличия throw/catch в коде? 😏
C++ отлично умеет работать без исключений, если хочется. пример: Chrome. нет никакой "непредсказуемости". Исключения возникают только там, где кто-то написал throw