The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз набора компиляторов LLVM 20

07.03.2025 15:30

После шести месяцев разработки доступен релиз проекта LLVM 20.1.0, развивающего инструментарий (компиляторы, оптимизаторы и генераторы кода), компилирующий программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован в машинный код для заданной целевой платформы или использован JIT-компилятором для формирования машинных инструкций непосредственно во время выполнения программы. На базе технологий LLVM проектом развивается компилятор Clang, поддерживающий языки программирования C, C++ и Objective-C. Начиная с прошлой ветки проект перешёл на новую схему формирования номеров версий, в соответствии с которой нулевой выпуск ("N.0") используется в процессе разработки, а первая стабильная версия снабжается номером "N.1".

Среди улучшений в Clang 20:

  • Реализованы возможности, развиваемые для будущего стандарта C2y:
    • Добавлены суффиксы "i" и "j" для обозначения мнимой части в комплексных числах (ранее были доступны в расширениях GNU "-Wgnu-imaginary-constant").
    • Поддержка указания диапазонов целых значений в выражениях "case", например, "case 1 ... 10:" (ранее было доступно в расширениях GNU "-Wgnu-case-range").
    • Запрещено использование квалификаторов и спецификаторов хранения классов для параметров типа void (например, "const void", "static void" и "register void").
    • Разрешено определение поведения объектов пустых структур и объединений (union) на усмотрение компилятора.
    • Обработка квалификаторов типов функций (например, const и volatile) теперь определяется на усмотрение компилятора. В Clang подобные квалификаторы игнорируются.
    • Изменена обработка неопределенного поведения, связанного с инициализацией.
  • Добавлены возможности, определённые в Си-стандарте C23:
    • Расширен диапазон значений, допустимых для элементов перечислений (enum) - значения теперь могут выходить за пределы типа int (быть больше INT_MAX и меньше INT_MIN).
    • Расширены возможности работы с перечислениями (enum): в перечислениях разрешено явно указывать базовый тип, отличный от типа int.
  • В режиме совместимости с компилятором msvc разрешено указывать спецификатор "inline" в объявлениях "typedef" для типов функций.
  • В заголовочный файл limits.h добавлены макросы LONG_LONG_* для библиотеки bionic, применяемой в Android.
  • Во всех режимах для языка Си ключевое слово "__nullptr" реализовано как псевдоним к "nullptr".
  • Добавлены новые встроенные макросы __INT8_C, __INT16_C, __INT32_C, __INT64_C, __INTMAX_C, __UINT8_C, __UINT16_C, __UINT32_C, __UINT64_C и __UINTMAX_C.
  • Для C++ добавлена поддержка продления времени жизни временных объектов, созданных с помощью агрегатной инициализации, которая использует инициализаторы по умолчанию.
  • Для C++ добавлены встроенные функции "__builtin_elementwise_popcount", "__builtin_elementwise_fmod", "__builtin_elementwise_minimum" и "__builtin_elementwise_maximum", а также встроенный псевдоним типа "__builtin_common_type" (для повышения производительности std::common_type).
  • Добавлены возможности, связанные с будущим стандартом C++2с (C++26):
    • Встроенная операция "__builtin_is_virtual_base_of" для проверки является ли базовый класс виртуальным.
    • Вариативный оператор "friend" ("friend Ts...").
    • Возможность использования ключевого слова "constexpr" с разновидностью оператора "new" (placement new) для размещения объекта в заранее выделенной памяти во время компиляции.
    • Добавлена встроенная функция "__builtin_is_within_lifetime", позволяющая проверить активность альтернативы в объединениях (union).
    • Объявлен устаревшим синтаксис определения вариативных параметров с многоточием без предшествующей запятой (например, когда указывается "void e(int...)" вместо "void e(int, ...)").
  • Добавлены возможности, связанные со стандартом C++23:
    • Убрано ограничение на возвращение функциями с признаком "constexpr" только литеральных типов (например, помимо таких типов, как int, float и char, теперь можно работать со структурами).
    • Обеспечена полная поддержка продления времени жизни временных объектов в циклах "for", использующих диапазоны.
    • Определён макрос "__cpp_explicit_this_parameter" и добавлена встроенная функция "__builtin_is_implicit_lifetime" для поддержки возможности использования типов с неявным временем жизни.
    • Добавлена поддержка использования в константных выражениях (constexpr) неизвестных указателей и ссылок, которые не могут быть определены на этапе компиляции.
  • В режиме C++20 реализован поиск на уровне модулей.
  • Добавлены новые флаги компилятора:
    • "-fc++-static-destructors={all,thread-local,none}" - определяет, какие переменные C++ имеют статические деструкторы.
    • "-fextend-variable-liveness" - сохраняет сведения об исходных переменных для улучшения отладки кода после оптимизации.
    • "-Warray-compare" - предупреждение о сравнении массивов в коде C++, не использующем стандарты C++20 и C++23. "-Warray-compare-cxx26" - выводит аналогичное предупреждение при использовании стандартов, начиная с C++26.
    • "-fwrapv-pointer" - включает диалект языка, в котором определено поведение при переполнении указателя.
  • В утилиты clang-cl и clang-dxc добавлена опция "-fdiagnostics-color=[auto|never|always]".
  • Включена по умолчанию генерация уникальных тегов для анализа псевдонимов (alias) на основе типов для несовместимых указателей (TBAA), позволяющая учитывать информацию о типах для выявления ошибок, возникающих, когда несколько разных указателей ссылаются на одну и ту же память. Для возвращения старого поведения можно использовать опцию "-fno-pointer-tbaa".
  • Применена более агрессивная оптимизация конструкций, допускающих неопределённое поведение при работе с указателями. Например, проверка "ptr + unsigned_offset < ptr" теперь будет обработана как значение "false", а не преобразована в "(ssize_t)unsigned_offset < 0", так как "ptr + unsigned_offset" может привести к неопределённому поведению при переполнении размера типа.
  • Прекращена поддержка целевых платформ RenderScript, le32 и le64. Удалена утилита clang-rename.
  • Расширены средства диагностики и статического анализа, добавлены новые проверки.

Основные новшества LLVM 20:

  • Добавлен новый проход IRNormalizer, выполняющий преобразование модулей LLVM в нормальную форму, используя перегруппировку и переименование инструкций, сохраняя при этом семантику. Нормализация упрощает сравнение семантики модулей, после их обработки разными проходами LLVM.
  • В число официально поддерживаемых целевых платформ принят бэкенд SPIR-V, реализующий возможность генерации переносимого промежуточного представления SPIR-V, совместимого с OpenCL и SYCL, и пригодного для использования при генерации шейдеров Vulkan, GLSL и HLSL. Бэкенд преподносится как альтернатива развиваемого консорциумом Khronos инструментария SPIR-V LLVM Translator.
  • В бэкенд для архитектуры RISC-V добавлена поддержка процессоров Hazard3 (-mcpu=rp2350-hazard3), Syntacore SCR4/SCR5/SCR5 (-mcpu=syntacore-scr4/5-rv32/64), Sifive p470 (-mcpu=sifive-p470), TT-Ascalon D8 (-mcpu=tt-ascalon-d8), MIPS P8700 (-mcpu=sifive-p550).

    Добавлена поддержка расширений: Zvbc32e, Zvkgs, Smctr, Ssctr, Svvptc, Smdbltrp, Ssdbltrp, Sdext, Sdtrig, Sha. В разряд стабильных переведена поддержка расширений Zacas, Smmpm, Smnpm, Ssnpm, Supm и Sspm. Стабилизированы профили RVA23U64, RVA23S64, RVB23U64 и RVB23S64. Добавлена экспериментальная поддержка ассемблера для расширений Qualcomm uC Xqcicsr, Xqcisls, Xqcia, Xqciac, Xqcics, Xqcilsm, Xqcicli, Xqcicm, Xqciint, Xqcilo.

  • В бэкенд для архитектуры AArch64 добавлена поддержка ассемблера и дизассемблера для архитектурных расширений Armv9.6-A. Добавлена поддержка процессора Fujitsu Monaka.
  • В бэкенд AMDGPU добавлена начальная поддержка GPU GFX950. Улучшена реализация операций llvm.memcpy, llvm.memmove и llvm.memset.
  • В бэкенд WebAssembly добавлен новый целевой CPU Lime1 (-mcpu=lime1). Добавлена поддержка нового стандартизированного механизма обработки исключений.
  • В бэкенд x86 добавлена поддержка CPU Intel Diamond Rapids (-mcpu=diamondrapids) и расширенных инструкций AVX10.2-256, AVX10.2-512, SM4(EVEX), MOVRS, MSR_IMM.
  • Улучшены бэкенды для архитектур ARM, LoongArch, MIPS и PowerPC.
  • В библиотеке Libc++ продолжена реализация возможностей стандартов C++20, C++23 и C++26.
  • В отладчике LLDB реализовано распараллеливание разбора разделяемых библиотек, что привело к ускорению запуска процесса отладки в среднем в два раза. На 30-60% ускорена индексация формата DWARF. Улучшена диагностика вычисления выражений.
    
       (lldb) p a+b
                ˄ ˄
                │ ╰─ error: use of undeclared identifier 'b'
                ╰─ error: use of undeclared identifier 'a'
    
    
  • Для сборки LLVM компилятором MSVC теперь требуется как минимум версия Visual Studio 2019 16.8.


  1. Главная ссылка к новости (https://llvm.org/...)
  2. OpenNews: Опубликован набор компиляторов LLVM 19
  3. OpenNews: Обеспечена возможность сборки ядра Linux в окружении macOS с LLVM
  4. OpenNews: Доступен набор компиляторов LLVM 18
  5. OpenNews: Выпуск компоновщика Mold 2.0, развиваемого разработчиком LLVM lld
  6. OpenNews: Проект Minotaur развивает оптимизатор векторных инструкций для LLVM
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/62846-llvm
Ключевые слова: llvm, clang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (59) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (3), 15:57, 07/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –16 +/
    Все никак не пойму зачем это нужно? Может кто нибудь объяснить на пальцах? Вроде написано что это, но не понятно зачем это нужно если есть ЯП которые собирают исполнимые двоичные файлы для целевых платформ.
     
     
  • 2.7, Аноним (7), 16:03, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну а чем, например, собрать раст для целевой платформы? А хотя да... лучше б не было этого LLVM, согласен.
     
  • 2.8, Скрудж (?), 16:08, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Чтобы авторы компилятора языка не решали одну и ту же задачу снова и снова: LLVM умеет и оптимизации делать, и до-компилировать на конкретном устройстве, и под различные платформы собирать. Теперь достаточно написать слой YourLang => LLVM IR, а всё остальное сделает за тебя LLVM, и сделает хорошо
     
     
  • 3.71, 12yoexpert (ok), 23:53, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну то есть всё как в gcc
     
  • 2.12, Аноним (12), 16:44, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Сейчас подробнейшим образом объясню на пальцах. Это нужно чтобы эпл могла скипнуть с х86 на arm , а в будущем на что угодно. Поэтому она полностью и проспонсировала разработку.
     
     
  • 3.75, Смузихлеб забывший пароль (?), 05:44, 09/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    яблоко спонсировало это гораздо раньше появления планов перехода на арм-подобное
    но у них это и в инструментарии давным-давно шло по умолчанию
     
  • 2.17, Аноним (17), 17:39, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Все никак не пойму зачем это нужно? Может кто нибудь объяснить на пальцах? Вроде написано что это, но не понятно зачем это нужно если есть ЯП которые собирают исполнимые двоичные файлы для целевых платформ.

    Потому что есть ЯП которые собирают двоичные файлы для целевых платформ LLVM'ом.

     
  • 2.19, Аноним (19), 18:51, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >не пойму зачем это нужно?

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

     
  • 2.33, Аноним (33), 22:22, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Применение смотри и поймёшь кому это надо. Всякие новомодные языки типа rust, утилиты дополнения кода и статические анализаторы, компиляторы шейдеров для видеокарт в OpenGL/OpenCL/Vulkan и т.д. Для видеокарт прям спасает, иначе шейдерных компиляторов были бы десятки. В webassembly LLVM прям спас, иначе хз сколько лет ждали бы поддержки C++, уже имея C-компилятор.

    Выше про переход с x86 на arm писали - там не особо нужно, с этим и gcc успешно справляется.

     
  • 2.58, анон (?), 11:02, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Байт код p-code Pascal применили в 1977 в UCSD Pascal. CLR (Common Language Runtime) .Net давным давно работает подобным образом.
     

  • 1.4, Bottle (?), 15:57, 07/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Шёл пятый год, как модули завозили в плюсы... Всё завозили, да не вывезли.
    Ждём стандарт C++29, который отменит модули.
     
     
  • 2.18, Аноним (17), 18:38, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    О чем вы? Юзаем модули уже второй или третий год в проде. И блочились они даже не об LLVM, а об поддержку в CMake.
     
     
  • 3.38, Аноним (38), 22:57, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    какие модули используете и как подключили к проекту?
     
  • 3.54, sdfm (?), 07:33, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А как вы боролись/боритесь с тем, что шаблоны в обычных заголовочных файлах, включённых в прелюды модулей получают двойное инстанцирование и в итоге всё фейлится в линкере с переопределением типов. Как минимум у GCC 13 было так. У clang'а в среднем чуть лучше, но тоже на проблемы с переопределением можно встрять. import std у них ещё не готов, т.е. даже стандартную библиотеку с модулями смешивать сложно.

    У вас вообще всё на модули переписано? Или у вас msvc only?

    А то я так-то тоже пришёл к выводу, что модули пока не готовы, как минимум до реализации import std.

     
  • 2.20, Аноним (19), 18:55, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • –4 +/
    К C++ применима пословица - Всё завозили, да не вывозили. Гора накопилась.) C++++++
     
  • 2.72, 12yoexpert (ok), 23:54, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    модули в плюсах нужны только вредителям из яндекса на зарплате, и ты один из них
     

  • 1.5, Аноним (5), 15:59, 07/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Я, кстати, выяснил, по какой причине не собирались программы вроде pcsx2 шлангом (зачем он там непонятно, по опыту pcsx3 производительность ощутимо ниже билдов gcc). Надо докинуть флагов -fsplit-lto-unit и -stdlib=libstdc++.

    А чтобы хромиум можно было собрать с некоторых пор надо добавлять --undefined-version линкеру. Когда хромиум обламывается в самом конце на линковке это не прикольно. Правда, ещё не решил такую проблему, что хромиум собирается только с вейландом или только с иксами, если собирать с обоими бинари падают с sigbus.

     
     
  • 2.16, Аноним (16), 17:27, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У крестов есть стандарт, да
     
  • 2.39, anonymous (??), 23:03, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В Генте хромиум конпеляется любым конпелятором с иксами, вейландом и ими обоими.

    Мне кажется, ты просто что-то делаешь не так.

     
     
  • 3.42, Аноним (5), 23:16, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В Генте хромиум конпеляется любым конпелятором с иксами, вейландом и ими обоими.
    > Мне кажется, ты просто что-то делаешь не так.

    Компиляется то компиляется. Но потом никак не запустить бинари. В моей генте cxxflags и ldflags переопределены под рекомендации нормальных дистрибутивов (все эти -fstack-protector-strong -fstack-clash-protection -D_GLIBCXX_ASSERTIONS -D_FORTIFY_SOURCE=3 -ftrivial-auto-var-init=zero), что периодически создаёт проблемы. А так я уже несколько раз пробовал.

     
  • 3.44, Аноним (5), 23:32, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Интеловский/амдшный компиляторы конечно точно нет, насчёт gcc не уверен, ты давно собирал? А то раньше то собиралось, хоть и требовало патчей. А теперь и firefox регулярно не собрать gcc и тащат ворох васянских патчей. Но в принципе при сборке gcc отключается часть оптимизаций в гугловских компонентах, хоть попугаи в бенчмарках и лучше. PGO ещё регулярно поломан, пока gcc собиралось по-моему проблем не было, теперь PGO только для шланга иногда работает и без PGO хорошие попугаи не получить.
     

  • 1.9, Аноним (7), 16:08, 07/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > error: use of undeclared identifier 'a'

    а показывает на "p"

     
     
  • 2.10, Скрудж (?), 16:13, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это если из под Lynx смотреть
     
     
  • 3.11, Аноним (7), 16:22, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Блин, точно. Сменил шрифт и все стало норм
     

  • 1.14, Аноним (12), 16:46, 07/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Чем это лучше чем jvm? Да я рофлю, я знаю что ничем.
     
     
  • 2.21, Афроним (?), 19:53, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это тоже от Эплы или все же другое?
     
  • 2.40, anonymous (??), 23:04, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты сравнил хер с пальцем.

    На первый взгляд похоже, но цели очень сильно различаются.

     
  • 2.45, _ (??), 23:43, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну как вариант - это ещё хоть кому нибудь надо, в отличии отЪ :-р
    Рофлить и мы умеем :)
     

  • 1.23, ИмяХ (ok), 21:20, 07/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >>более агрессивная оптимизация конструкций, допускающих неопределённое поведение при работе с указателями. Например, проверка "ptr + unsigned_offset < ptr" теперь будет обработана как значение "false", а не преобразована

    Отличная идея для бэкдора!

     
  • 1.24, Аноним (24), 21:21, 07/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Великий и могучий LLVM 20 вновь осветил своим незыблемым сиянием горизонты прогр... большой текст свёрнут, показать
     
     
  • 2.34, Аноним (7), 22:29, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Красивое
     
  • 2.49, Аноним (49), 00:44, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Расширения C++2c и C++23 вновь доказывают: язык, на котором пишут ядра операционных систем

    Не пишут.

     

  • 1.27, Аноним (27), 21:27, 07/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так почему паскаль считался менее производительным, нежели си? Неужели просто компиляторы были недостаточно вылизаны?
     
     
  • 2.29, Аноним (29), 21:37, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Не так. C красив. Pascal страшен (на вид). Перефразируя Туполева: "Хорошо летает только красивый самолет".
     
     
  • 3.30, Аноним (30), 21:47, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > C красив.

    Шутка месяца, как минимум.

     
     
  • 4.37, anba (?), 22:51, 07/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет не шутка. Синтаксис сишечки божественен, в отличии от ... :)))

    п.с. flame mode off

     
     
  • 5.48, Neon (??), 00:14, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Pascal'ем хорошо пытать, его любят теоретики в ВУЗах, которые на практике палец об палец не ударили. Ну и древние пенсионеры преподы, которым влом что то новое учить. Некоторые, вообще, Fortran'ом перебиваются еще с 60х.)))
     
     
  • 6.51, Аноним (51), 05:04, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В ВУЗах учат не практике — этому научить всё равно невозможно — а программированию. И для обучения программированию подходит буквально любой язык. Да, даже Malbolge и Brainfuck. Но так как никто не обладает бесконечным временем, обычно выбирают что-нибудь более оптимальное — Лиспы, Паскаль, Фортран, Питон, инода Яву или даже С++. К сожалению, студенты часто путают умение кодить с умением программировать, а профессуре столько не платят, чтобы каждого бедолагу распутать и указать на ошибки мышления и мировосприятия. Так и выходят в мир кодеры, впоследствии гордо именующие себя «программистами на языке $x», которые в итоге попадают на опеннет и рассказывают как их учили не тому языку.
     
     
  • 7.52, Аноним (52), 06:41, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вижу три градации оценки высшего образования 1 Вуз готовит полноценного специа... большой текст свёрнут, показать
     
     
  • 8.55, Хо (?), 09:00, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В армии служили То что происходит в армии, остаётся в армии ... текст свёрнут, показать
     
     
  • 9.67, Аноним (-), 18:06, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Служил Туалеты чистил, плац лопатой ковырял Избиения от сержантов По ночам не... текст свёрнут, показать
     
  • 8.66, Аноним (66), 15:52, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет и трижды нет, совковое образование - дрессировка Человек учится сам, а преп... текст свёрнут, показать
     
  • 3.47, Neon (??), 00:12, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Занудный Pascal любят такие же зануды в ВУЗах. А вот на практике его терпеть не могут люди практичные, которым влом писать целые предложения там, где тот же С/С++ обходится несколько буквами. Все эти begin/end, которые заменяются  парой символов {}, вся эта муть с array of integer и прочим. Язык созданный теоретиками, которые палец об палец не ударили на практике. Да, современные IDE могут частично упростить работу, но всё равно многословие раздражает
     
     
  • 4.50, Аноним (66), 02:41, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > но всё равно многословие раздражает

    коровы мычат, барашки - бээкают, но ни тех ни тех моя твоя не понимать.

     
  • 4.56, Аноним (56), 09:05, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Pascal любят люди, общающиеся на человеческом языке (human language).
    C/C++ любят з@др0ты/п$tу%i, общающиеся на пт|чь$м я^ык$ ({[!@#$%^&*_+|<>}]).
     
     
  • 5.57, Аноним (57), 09:37, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ой вей, шо делается, шо делается? Таки ви с таким сурьёзнвм видом транслируете такие огромние  глупости. Поедте на Привоз и спросите там у любого босяка "Изя, какой язык программирования напоминает человеческий" и он вам таки ответит за это "конечно COBOL - на нем еще тетя Соня програмувала в том веке пока еще была жива".
     
  • 5.60, Аноним (-), 11:46, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Pascal любят люди, общающиеся на человеческом языке (human language).
    > C/C++ любят з@др0ты/п$tу%i, общающиеся на пт|чь$м я^ык$ ({[!@#$%^&*_+|<>}]).

    Вы точно в этом уверены? Зайдите на википедию, куда-нибудь в раздел по полям Галуа например. Хотя можете и какое-нибудь уравнение Максвелла в релятивистской форме накопать. И это тоже - люди общаются, если что. На этом фоне C++ кстати будет не такой уж и сложный.

     
     
  • 6.62, Анонем (?), 13:15, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Математическая нотация тоже тот еще комбайн из костылей. Там давно напрашивается реформа. Правда математики на это не пойдут, ведь тогда они станут чуточку более обычными людьми.
     
     
  • 7.65, Аноним (66), 15:45, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Там давно напрашивается реформа

    математика последние 300 лет существует только для математиков, и раз в столетие появляется какой-нибудь Гедель и приземляет их, или Брауэр готовый сж*чь их всех. А последний век вообще поставили на финансовые рельсы, теперь это не наука, а продукт.

     
  • 7.77, BeLord (ok), 23:56, 09/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    И зачем там реформа? Вот к примеру матрицы, дифуры, ряды, интегралы и прочее используемое каждый день в том же ИТ, все весьма прозрачно и стройно и уж явно прозрачнее, чем АПИ какого-нибудь продукта, написанного любителями экзотики.)
     
     
  • 8.78, Аноним (52), 06:10, 10/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я не он, но скажу, что для нотации, используемой в доказательствах, реформа бы п... текст свёрнут, показать
     
  • 5.74, Аноним (52), 01:38, 09/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Pascal любят люди
    > ,
    > общающиеся на человеческом языке
    > (
    > human language
    > )
    > .

    Смотри, это знаки препинания. Они второстепенны и поэтому сделаны маленькими (не зпт, скб, тчк). Так и в программировании - begin, then, end отвлекают внимание от более важных конструкций. Видимо, Pascal любят люди-телеграфисты.

     
  • 4.59, анон (?), 11:07, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В Паскале нет неявного преобразования типов в отличие от (впиши нужное). Вот для этого эта "муть":P
     
  • 4.61, Аноним (30), 12:08, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Язык должен быть читаемым, в первую очередь.
     
  • 4.63, Анонем (?), 13:24, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Язык созданный теоретиками, которые палец об палец не ударили на практике.

    Вирт так-то полноценную архитектуру спроектировал и реализовал, включая железо, ось, язык и
    инновационный ГУИ.
    https://en.wikipedia.org/wiki/Ceres_(workstation)

     
  • 2.64, n00by (ok), 14:14, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Да.
     
  • 2.68, Аноним (68), 19:16, 08/03/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Считался кем?! Трепологами, которые "на глаз" определяли попугаи?
    Турбо Паскаль был прекрасным канпелятором, что даже трудно было определить этап компиляции - МГНОВЕННО запускал маленькие программы!
     
     
  • 3.73, anonymous (??), 00:11, 09/03/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если в компиляторе вообще нет оптимизации он безусловно будет быстрым.
     
     
  • 4.76, blevakagmail.com (?), 06:21, 09/03/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сколько лет на Турбо Паскаль кодите?
     

  • 1.69, Аноним (68), 19:17, 08/03/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Почему бы к этим заплесневелым сипипям не добавить, что на LLVM пилится компилятор Ди? (проект LDC)
    Вот как раз нытики про "скорость" могут убедиться - всё работает не хуже Сей.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру