LLVM Foundation одобрил включение компилятора F18 в проект LLVM

Также проекту F18 было рекомендовано рассмотреть возможность избавления привязки к стандарту C++17

Правильно. Скоро ведь уже C++20 будет – пора бы уже задуматься о переходе.

Goto

теперь ещё есть оператор Entry, позволящий внутри одной процедуры/функции указывать точку входа для другой.

Жив курилка

теперь ещё есть оператор Entry, позволящий внутри одной процедуры/функции указывать точку входа для другой.

Entry был ещё в Fortran 77, есть что-то новое?

Когда же добавят компилятор PL/I???

Интересно, надо погонять на перегонки с интеловским. Если будет свободный фортран не хуже интеловского, то и замечательно.

Вот самому интересно. Видимо никогда, здоров он больно :)

Ещё лучше, что он был и в 77.

Даладно! Вычислимый goto запретили :)

У них все еще есть Ада для этих целей :)

Арифметический IF то есть?

И его, и тип label

LABEL IGO
ASSIGN 100 TO IGO
GOTO IGO

Вычислимый goto — это вот это:

GOTO (1000, 44, 196) I - 17

в нём нет ffast-math и из-за этого выполнение кода с вычислениями медленнее в 4-5 раз

Как я понимаю, подобные оптимизации можно проводить руками без выхода за рамки стандартных операций. Так что достаточно просто подумать, прежде чем кодить формулы.

Не совсем. Эта опция отрубает кучу проверок в процессе вычислений.

Ещё march=native бывает полезна, если собирать под конкретную машину.

Вон Embarcadero компиляторы для Delphi перевела на LVMM.

С какой версии Делфи? Компоненты бесплатыми станут?

конкретную

Не обязательно, с -mavx2 будет работать на любом процессоре (всё что его не поддерживает - не процессоры, раз уж у нас тут серьёзные вычисления).

Ну в большинстве задач узкое место - шина данных, а не пинание регистров. Факториалы редко кому нужны.

C++ тупо удобнее, мощнее и безопаснее, чем C. Чем сложнее софт, тем это отчетливее видно.

Торвальдсу это скажи.

Вычисляемому goto слава.

Года с 2015, может раньше.

У них сначала сильно урезанные бесплатные starter edition были, а в прошлом году, летом, стал бесплатно доступен community edition с кучкой визуальных компонентов и ограниченной коммерческой лицензией.

Это понятно, но вот такие постоянные проверки могут, например, помешать компилятору векторизовать код.

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

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

Торвальдсу это скажи.

Почему же в MS, Apple и Google Торвальдса не послушали, а?

Приговаривал Балда с укоризной: -Не гонялся бы ты, поп, за дешевизной.

С учетом того, что MS, Apple и Google делают свои ОС за свои же деньги (т.е. в рамках строков и бюджетов), тут еще большой вопрос, кто за дешевизной погнался.

Много компиляторов на си написал? Большинству хватает одного, чтобы понять почему лучше взять OCaml.

Поправил.

даже не Java и C#, а на Python-ы, Ruby и JavaScript. Но вот, незадача, там за безопасность приходится платить производительностью

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

Во-вторых, вся эта скриптоинтерпретируемая шатия никакого отношения к повышению безопасности не имеет. Разговоры о том, что выбор языка программирования может как-то там повысить безопасность, ведутся уже десятки лет, и пора бы понять, что все эти разговоры безнадёжно оторваны от реальности. Всевозможные injection'ы интерпретируемых языков ничем не лучше какого-нибудь buffer overflow, которое можно сделать на Си, наоборот — их даже проще исполнить. А ещё есть такой момент, что дыра в программе на Си — это всегда результат безалаберности автора программы, тогда как дыра в конгломерате интерпретатора с интерпретируемым кодом может оказаться вообще-то в интерпретаторе.

Так что если кто платил за безопасность — может считать, что его кинули: цену содрали, безопасности не дали.

Что до C++, то есть сильно разные варианты понимания, что такое C++. Если под C++ понимать C++17 в сочетании с STL, да даже и C++98 в сочетании с STL, то на этом бастарде _могут_ писать полные идиоты, не понимающие, чем список отличается от массива, при этом всё великолепие чистого Си оказывается к их услугам. Кабы они сами себе ноги отстреливали, настал бы рай, но увы — отстрелить можно не только ногу и не только себе. О какой производительности и о какой безопасности может идти речь при использовании такого инструмента — непонятно.

Ну так ценность Rust-а в его безопасности.

Из этого следует, что ценность Rust равна нулю. Безопасность не имеет никакого отношения к используемому языку программирования.

NB: нет, я не знаю Rust и не утверждаю, что он не нужен. Я лишь утверждаю, что (а) вопросы безопасности и вопросы выбора языка программирования между собой никак не связаны, (б) никакие свойства языка программирования не могут повлиять на безопасность ни в какую сторону, если только это не дыры в трансляторе и (в) разговоры о том, что чистый Си якобы как-то там снижает безопасность, представляют собой чистый миф.

Ба, какой высочайшей пробы дистиллят.

А еще чего-нибудь такого же можете выдать? Читал бы и читал.

Почему же в MS, Apple и Google Торвальдса не послушали, а?

Не знаю как в MS (и вправду, чего это они Торвальдса не послушали), но я что-то пока не слышал, чтобы Apple или Google начали ядра на плюсах писать.

Читал бы и читал.

Понравилось? http://www.stolyarov.info и не благодари

но я что-то пока не слышал, чтобы Apple или Google начали ядра на плюсах писать.

Не знаю, что там у Apple-овского ядра внутри, но околоядерные вещи там пишутся на плюсах: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/K...

У Google в разработке новая ОС Фуксия, в которой используется C++14 и Rust. Плюс Dart и Go сверху.

но околоядерные вещи

«Околоядерные» можно хоть на коболе писать, какая разница. Точнее, разница есть, безусловно, но она не такая, чтобы вообще невозможно было.

А вот в ядре (и вообще «на голом железе», это не обязательно именно ядро ОС, может быть и firmware) условия существования от обычных несколько отличаются, налагая свои ограничения в том числе и на выбор инструментария.

У Google в разработке новая ОС Фуксия, в которой используется C++14 и Rust. Плюс Dart и Go сверху.

В истории уже были попытки писать операционки на C++, как впрочем и на Паскале, и на Обероне, и, кажется, даже на джаве. Пока что ни одна такая попытка не взлетела (э-ммм... ну, мы не будем считать операционками Windows 1.0 и 2.0 образца восьмидесятых, правда? :) Ну а эта не взлетит совершенно точно: множество людей, понимающих, как устроена ОС, не имеет пересечения с множеством тех, кто полагает использование C++14 допустимым (для чего бы то ни было, не только для ОС).

А-а-а!

А.В.Столяров, «Введение в язык Си++», издание четвертое:

Если под «языком Си++» понимать C++17, то о применении такого инструмента на практике не может быть никакой речи, т.е. с языком Си++ следует попрощаться, устроить торжественные похороны и поискать альтернативу; впрочем, то же самое можно сказать про все его «стандарты», начиная с самого первого, принятого в 1998 году; строго говоря, язык Си++ как уникальное явление был уничтожен именно тогда.

Как я до сих пор жил не зная столь выдающегося автора?...