The OpenNET Project / Index page

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

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

08.09.2017 10:46

После шести месяцев разработки представлен релиз проекта LLVM 5.0 (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.

Напомним, что в соответствии с новой нумерацией версий осуществлён уход от разделения значительных и функциональных выпусков. В каждом функциональном обновлении теперь меняется первая цифра (например, весной следующего года состоится релиз LLVM 6.0.0). Для обеспечения совместимости с существующими системами разбора номеров версий LLVM корректирующие обновления, как и раньше приводят к увеличению третьей цифры (5.0.1, 5.0.2, 5.0.3).

Из новых возможностей LLVM 5.0 отмечается полная реализация стандарта C++17, поддержка сопрограмм в C++, реализация GNU-расширения для неявного скалярного преобразования в вектор, новые оптимизации и средства диагностики ошибок.

Улучшения в Clang 5.0:

  • Поддержка расширения для использования сопрограмм в коде на C++ (пример кода). Для включения следует использовать опции "-fcoroutines-ts -stdlib=libc++";
  • Обеспечена полная поддержка стандарта C++17. Для активации режима C++17 следует использовать флаг "-std=c++17" ("-std=c++1z" оставлен для обеспечения совместимости);
  • Новые возможности для диагностики:
    • "-Wcast-qual" для проверки корректности приведения типов в Си-стиле для C++;
    • "-Wunused-lambda-capture" для выявления переменных, захваченных лямбда-выражением, но не используемых в теле лямбда-выражения;
    • "-Wstrict-prototypes" для выявления не-прототипных функций, определений блоков и типов в Си и Objective-C;
    • "-Wunguarded-availability" для информирования об использовании новых API, которые были представлены в системе, версия которой новее версии системы, заданной в качестве целевой. Также добавлен сокращённый вариант "-Wunguarded-availability-new", который охватывает проверку версий API, выпущенных после macOS 10.13, iOS 11, tvOS 11 и watchOS 4;
    • "-Wdocumentation" - позволяет использовать в комментариях директивы \param и \returns для задания типа указателя для блока или функции;
  • Добавлен новый флаг компилятора "--autocomplete" для вывода списка флагов и их аргументов для применения в системах автодополнения ввода;
  • Объявлены устаревшими и игнорируются флаги "-fslp-vectorize-aggressive" (заменён нормальным векторизатором SLP) и "-fno-slp-vectorize-aggressive" (данное поведение теперь всегда используется по умолчанию);
  • Добавлена новая pragma attribute для применения атрибута к нескольким декларациям;
  • Для языков Си++ и Си реализовано GNU-расширение для неявного скалярного преобразования в вектор. Пример преобразования скалярного значения в вектор (ко всем элементам вектора "a" будет прибавлено 5):
    
       typedef unsigned v4i32 __attribute__((vector_size(16)));
       v4i32 foo(v4i32 a) {
          return a + 5;
       }
    
  • Clang 5 станет последним выпуском, в котором по умолчанию используется режим "-std=gnu++98" при использовании совместимого с GCC драйвера clang++. Начиная со следующего выпуска будет применяться режим "-std=gnu++14" для совместимости с поведением новых выпусков GCC. Пользователям рекомендуется добавить в файлы сборки опции для явного определения используемой версии стандарта;
  • Устранена порция ошибок в реализации OpenCL, расширен тестовый набор для OpenCL, расширена диагностика, в руководство добавлена документация по OpenCL. Обеспечена поддержка расширения cl_khr_subgroups и атрибута intel_reqd_sub_group_size. В CIndex добавлены типы OpenCL;
  • В clang-format добавлена опция BreakBeforeInheritanceComma для подстановки разрывов после ":" и "," при определении класса. Опция включена по умолчанию при выборе стиля оформления кода Mozilla. Обеспечено выравнивание комментариев. Обеспечена автоматическая подстановка комменария с именем пространства имён в конце его определения;
    
       class MyClass
           : public X
           , public Y {
       };
    
       /* line 1
        * line 2
        */
    
       namespace A {
          int i;
          int j;
       } // namespace A
    
  • В Libclang обеспечена поддержка автодополнения кода для следующих конструкций C++: static_assert, alignas, constexpr, final, noexcept, override и thread_local. Добавлено автодополнения для членов зависимых классов;
  • В linter clang-tidy добавлена большая порция новых проверок, реализованы новые модули bugprone и hicpp;
  • В статическом анализаторе добавлена поддержка автоматического доказателя теорем Z3, созданного в Microsoft Research для верификации кода своих продуктов. По сравнению с предлагаемым по умолчанию доказателем теорем Z3 работает примерно в 15 раз медленнее, но позволяет обрабатывать более сложные запросы. Для включения Z3 требуется сборка с опцией "CLANG_ANALYZER_BUILD_Z3=ON" и указание флагов "-Xanalyzer -analyzer-constraints=z3";
  • Расширены возможности компонента UBSan (Undefined Behavior Sanitizer) с реализацией детектора неопределенного поведения, выявляющего во время выполнения программы ситуации, когда поведение программы становится неопределенным:
    • Добавлены и включены по умолчанию новые средства для проверки переполнения указателей (-fsanitize=pointer-overflow).
    • Реализованы проверки для определения нарушения аннотаций о значениях NULL (-fsanitize=nullability) в аргументах функций, операциях присвоения и значениях return.
    • Обеспечено определение некорректной загрузки из битовых полей (bitfields) и булевых наборов ObjC.
  • В биндингах для языка Python обеспечена поддержка обеих веток - Python 2 и Python 3.

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

  • В компоновщике LLD решены многие проблемы с совместимостью, реализован более читаемый формат сообщений об ошибках, добавлена опция "-Map" для вывода схемы с сопоставлением входных файлов с результирующим файлом, значительно ускорена работа опции "--gdb-index ", добавлена поддержка нестандартных перестановок R_X86_64_8 и R_X86_64_16, по умолчанию обеспечено заполнение добавочных блоков в текстовых сегментах инструкцией INT3 вместо нулевых байтов. Добавлены новые опции: -compress-debug-sections, -emit-relocs, -error-unresolved-symbols, -exclude-libs, -filter, -no-dynamic-linker, -no-export-dynamic, -no-fatal-warnings, -print-map, -warn-unresolved-symbols, -z nocopyreloc, -z notext, -z rodynamic;
  • В оптимизаторе циклов Polly, поддерживающем несколько техник оптимизации циклов и позволяющем организовать автоматическое распараллеливание кода с задействованием OpenMP, обеспечена поддержка компиляции всех компонентов платформы Android и пакета FFMPEG;
  • Представлена новая библиотека BinaryFormat, в которую перемещены определения структуры file_magic и функций identify_magic, а также структур и определений для форматов DWARF, ELF, COFF, WASM и MachO;
  • Утилита llvm-pdbdump переименована llvm-pdbutil, так как она уже давно переросла из программы для дампа содержимого PDB в полноценный инструмент диагностики и манипуляции содержимым PDB;
  • Удалена стадия векторизации BBVectorize, на смену которой пришёл векторизатор SLP;
  • Добавлена утилита opt-viewer.py для визуализации сведений о выполненных оптимизациях в формате HTML на основании YAML-отчёта, генерируемого опцией "-fsave-optimization-record";
  • Добавлен новый CMake-макрос LLVM_REVERSE_ITERATION;
  • Добавлена утилита llvm-dlltool для создания коротких библиотек импорта из файлов с определениями в стиле GNU. Поддерживаются форматы импорта PE COFF SPEC Import Library и PE COFF Auxiliary Weak Externals;
  • Для архитектуры x86 добавлена поддержка CPU Intel Goldmont, реализован планировщик для CPU AMD Ryzen (znver1), обеспечено более агрессивное развёртывание (inlining) вызовов memcmp. Добавлена поддержка инструкций AMD Lightweight Profiling (LWP), avx512vpopcntdq и инструкций AVX512 для ротации векторов. Добавлена возможность трассировки процессов и core-файлов NetBSD в одном потоке LLDB;
  • В бэкенд AMDGPU добавлена поддержка архитектуры Radeon GFX9, используемой в GPU Vega;
  • Внесены многочисленные улучшения в бэкенды для архитектур AArch64, ARM, AVR, MIPS и PowerPC, в том числе добавлена поддержка инструкций ARMv 8.1, 8.2 и 8.3, большой порции расширений POWER ISA 3.0, MIPS MT ASE и оптимизаций размера для microMIPS.


  1. Главная ссылка к новости (http://lists.llvm.org/pipermai...)
  2. OpenNews: Релиз набора компиляторов LLVM 4.0
  3. OpenNews: Создатель LLVM и Swift уходит из компании Apple
  4. OpenNews: Проект LLVM переходит на новую схему нумерации выпусков
  5. OpenNews: Проект LLVM планирует сменить лицензию
  6. OpenNews: LLVM и Clang включены в основной состав OpenBSD
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/47154-llvm
Ключевые слова: llvm, compile, clang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:04, 08/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > После шести месяцев разработки

    Теперь будут номер инкрементировать каждые полгода?

     
     
  • 2.2, Аноним (-), 11:18, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да, судя по "весной следующего года состоится релиз LLVM 6.0.0".
     
  • 2.3, Andrey Mitrofanov (?), 11:18, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >> После шести месяцев разработки
    > Теперь будут номер инкрементировать каждые полгода?

    Они уже совсем Большие и GCC-совместимые: http://www.opennet.dev/openforum/vsluhforumID3/102196.html#21 _Умные_!

    У них Нумерация!!11111

     
     
  • 3.8, Аноним (-), 11:53, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Помнится кое-кто раньше все твердил, что CLANG никогда даже близко не сравнится с GCC!
    )))
     
     
  • 4.9, КО (?), 12:04, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кто ж мог подозревать, что в компилятор, единственным преимуществом которого декларировали скорость компиляции начнут вставлять патчи от Мелкомягких, которые будут замедлять работу его статического анализатора в 15 раз. Таким нечестным приемом Шланг действительно сможет обойти всех по показателю время работы. :)
     
     
  • 5.13, Аноним (-), 12:14, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто ж мог подозревать, что в компилятор, единственным преимуществом которого декларировали скорость компиляции начнут вставлять патчи от Мелкомягких, которые будут замедлять работу его статического анализатора в 15 раз.

    То есть вы уверены:
    - что это декларировалось как единственное преимуществом;
    - что в GCC нет патчей от MS только потому что это открыто не афишируется.

    Как и все жертвы радикального маркетинга (по причине собственной некомпетентности), хоть от GNU, хоть от MS, вам кажется честным тот, кто больше всех кричит, что он якобы честный, а вовсе не тот, кто честно говорит все как есть, даже если большинству это не нравится.

     
     
  • 6.19, Andrey Mitrofanov (?), 13:11, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  - что в GCC нет патчей от MS только потому что
    > это открыто не афишируется.

    Да, пусть. Лишь бы здорове ^W CLA FSF-у под/для GPLv3+ отписали.

     
  • 5.14, iPony (?), 12:28, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Компиляция и статистический анализ - это вещи разные.
    К тому же непонятна сходу полезность/бесполезность более лучшего, но и более медленного анализатора.
     
     
  • 6.15, Аноним (-), 12:37, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > статистический анализ

    статический

     
  • 4.18, Andrey Mitrofanov (?), 13:09, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Помнится кое-кто раньше все твердил, что CLANG никогда даже близко не сравнится
    > с GCC!
    > )))

    Да, теперь шлангистам есть, чем ответить: они усиленно форсят сравнение.

    Очень люблю ту часть, где они считают __проценты__, сколько ещё ядра fbsd [или чего у них там] не собирает их binutils-замена.  "80% совместимости", представляете?!

     
     
  • 5.21, Аноним (-), 13:26, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Помнится кое-кто раньше все твердил, что CLANG никогда даже близко не сравнится с GCC!
    >> )))
    >
    > Да, теперь шлангистам есть, чем ответить: они усиленно форсят сравнение.
    > Очень люблю ту часть, где они считают __проценты__, сколько ещё ядра fbsd [или чего у них там] не собирает их binutils-замена.  "80% совместимости", представляете?!

    Так это были вы что ли? А то я уже забыл, кто именно.

    А еще помнится, кто-то вначале твердил, что clang никогда не сможет собрать ядро ОС. Тоже не помню, кто именно так говорил, помню только что он очень упорно стоял на своем.

    Самое интересное, чем всех этих людей так задевает сам факт существования llvm/clang?

     
     
  • 6.22, Andrey Mitrofanov (?), 13:59, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >кто-то вначале твердил, что clang никогда не сможет собрать
    > ядро ОС. Тоже не помню, кто именно так говорил, помню только
    > что он очень упорно стоял на своем.

    Сам придумал, сам поспорил? Сам-о-стоятеный!

    > Самое интересное, чем всех этих людей так задевает сам факт существования llvm/clang?

    Вы не понимаете, над Вами смеются. Я ж говорю, мажорно-позитивная новость.

    Очень радует, как проприертарщики переписывают GPL-код.  Очень!! Потеют, пыжатся. Мо-лод-цы же.  GPL работает.

     
     
  • 7.23, Аноним (-), 14:15, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>кто-то вначале твердил, что clang никогда не сможет собрать ядро ОС. Тоже не помню, кто именно так говорил, помню только что он очень упорно стоял на своем.
    >
    > Сам придумал, сам поспорил? Сам-о-стоятеный!

    Боитесь, что про вас плохо подумают?
    Про тех, кто плохо думет, не разбираясь, обычно тоже плохо думают, без разбору.

    >> Самое интересное, чем всех этих людей так задевает сам факт существования llvm/clang?
    >
    > Вы не понимаете, над Вами смеются. Я ж говорю, мажорно-позитивная новость.

    Андреи Митрофановы смеются над Анонимом.

    > Очень радует, как проприертарщики переписывают GPL-код.  Очень!! Потеют, пыжатся. Мо-лод-цы же. GPL работает.

    Все-таки похоже это был кто-то из Андреев Митровановых.

     
  • 7.27, Михрютка (ok), 20:05, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Очень радует, как проприертарщики переписывают GPL-код.  Очень!! Потеют, пыжатся. Мо-лод-цы
    > же.  GPL работает.

    Митрофанов, вы что-то сегодня рановато газовать начали. какой gpl код, кто переписывает? сгоняйте молодого за закуской, если самому ходить лень.


     
     
  • 8.34, Andrey Mitrofanov (?), 22:55, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мозги совсем пропил, проецирующий, родной wiki freebsd org GPLinBase --- пьяны... текст свёрнут, показать
     
  • 7.35, АнонимныйБобр67 (?), 23:00, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    MIT, BSD for-ever. Нет gpl. Ограничивать свободу ради свободы - это то ещё извращение.
    Мир свободного ПО уже устоялся и 80 давно прошли GPL изжила себя, вот. Да и тем более ей уже и во вред начинаются пользоваться. Лол.
     
     
  • 8.37, Andrey Mitrofanov (?), 23:09, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты пишешь это с xBSD А то и с macos-x Чем докажешь _Тебе_-то во вред И др... текст свёрнут, показать
     
     
  • 9.44, Аноним (-), 10:17, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Здесь уже Андреи Митрофановы пытаются подражать Анониму И судя по количеств... большой текст свёрнут, показать
     
  • 9.47, Аноним (-), 15:28, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в сортире или где посмотри наконец-то статистику - под MIT BSDL X11 Apache соз... текст свёрнут, показать
     
     
  • 10.63, Andrey Mitrofanov (?), 12:47, 12/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да Твоя голова -- очередной тому пример Враньё Оно же -- статистика от прихво... текст свёрнут, показать
     
  • 3.28, yet another anonymous (?), 20:06, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Они уже совсем Большие и ...

    Что "совсем Большие" --- это точно. Не затруднит размер этого дела для публики огласить?

     
  • 2.6, пох (?), 11:46, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    инвест...финансовые спекулянты по другому не понимают.
    А жрать разработчикам что-то надо.

     

  • 1.4, Andrey Mitrofanov (?), 11:29, 08/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода),

    Скромные, работящие ребяты. Мо-лод-цы.

    Очень мажорно и пятнично. Ура.

    > -  В статическом анализаторе добавлена поддержка автоматического доказателя теорем Z3
    > созданного в  Microsoft Research для верификации кода своих продуктов. По
    > сравнению с предлагаемым по умолчанию доказателем теорем Z3 работает примерно в
    > 15 раз медленнее, но позволяет обрабатывать более сложные запросы. Для включения

    Ужо-то GPLv3+ - ники-то обзавидуются!1  Микрософт!1111  Невиданный успех и прорыв.

    ...
    > архитектуры x86 добавлена поддержка CPU Intel Goldmont,

    "Что такое 'сколопендра', я не знаю. Но звучит красиво!"

     
     
  • 2.10, leap42 (ok), 12:10, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    сколопендра - это многоножка, если от Msft, то человеческая :-D
     
     
  • 3.20, Andrey Mitrofanov (?), 13:20, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > сколопендра - это многоножка, если от Msft, то человеческая :-D

    Надо прекращать писать на опенет. Говорят, мазги разжижает....
    https://www.anekdot.ru/id/-112521043/
    https://otvet.mail.ru/question/55886760

     
     
  • 4.29, Михрютка (ok), 20:06, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> сколопендра - это многоножка, если от Msft, то человеческая :-D
    > Надо прекращать писать на опенет. Говорят, мазги разжижает....
    > https://www.anekdot.ru/id/-112521043/
    > https://otvet.mail.ru/question/55886760

    закусывать надо, Митрофанов, закусывать.

     
  • 2.17, trolleybus (?), 12:52, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мажорно и пятнично - потому что 5-я мажорная версия?
     

  • 1.7, A.Stahl (ok), 11:50, 08/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пусть пилят. Даже мне, пользователю GCC, от них есть польза -- в моей любимой IDE кусок Шланга используется для реалтаймового парсинга кода.
     
     
  • 2.11, leap42 (ok), 12:12, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    да и открытые драйвера на видео (кроме intel) активно его используют
     
  • 2.41, Аноним (-), 05:28, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Местным аналитикам, все что не жпл то враг народа...
     

  • 1.12, Michael Shigorin (ok), 12:12, 08/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > GCC-совместимого

    Не хватает звёздочки и мелкого шрифта: "только вложенные функции и VLA будут примерно никогда".

     
     
  • 2.24, Аноним84701 (ok), 16:17, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > и VLA будут примерно никогда

    Да есть оно [variable length arrays] там. И для сишного – поддержка С99 все же "обязывает". И для плюсов (вроде как по умолчанию, пока не отключишь с помощью  "-Werror=vla").

     
  • 2.26, Ordu (ok), 20:03, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > только вложенные функции и VLA будут примерно никогда

    Вложенные функции в C требуют исполняемого стека. Или ещё какой-то ёмкости, которая одновременно write и execute. В C++/rust ещё можно выкрутиться имея разные типы указателей для функций захватывающих окружение на стеке и для функций не захватывающих его, но в C так не удастся. Точнее опять же можно, сделать и это (через расширение языка), но не тем способом, как это сделано в gcc.

    И кому нужны такие вложенные функции? Их никто и не пользует.

     
  • 2.31, KonstantinB (ok), 20:39, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Честно говоря, вообще не понимаю смысла во вложенных функциях в С.
    Единственное, что приходит в голову - в комбинации с другим gcc-расширением, statement expressions, можно изобразить типа-лямбды; но учитывая, что лямбды получатся локальные (валидные только в скоупе функции, где они объявлены), их не получится использовать там, где они особо бы пригодились - как колбэки в FSM-серверах на libevent/libev/libuv, - польза очень сомнительная.
     
     
  • 3.38, Александро (?), 23:37, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    "Честно говоря, вообще не понимаю смысла во вложенных функциях в С.
    Единственное, что приходит в голову - в комбинации с другим gcc-расширением, statement expressions, можно изобразить типа-лямбды; но учитывая, что лямбды получатся локальные (валидные только в скоупе функции, где они объявлены), их не получится использовать там, где они особо бы пригодились - как колбэки в FSM-серверах на libevent/libev/libuv, - польза очень сомнительная."
    Мне лично очень нехватало вложеных функций после ухода с Паскаля/Дельфы. Заменять их приходилось костылями, к коим с течением времени привык настолько что они кажутся теперь не костылями а родными протезами.
    это прекрасная штука. то что они отсутствуют в С/С++ илюстрирует родовую травму этих языков.
    Так что да - если вы никогда не програмировали с ними, то вьехать в их необходимость получится только с опытом.
     
     
  • 4.49, KonstantinB (ok), 16:31, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я программирую в основном на языках, где есть полноценные замыкания. Польза от них настолько очевидна, что не обсуждается. А вот польза от банальных вложенных функций не ясна.
     
     
  • 5.60, Alexandro (??), 11:01, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >А вот польза от банальных вложенных функций не ясна.

    фложенная функция видит контекст своего вызова - локальные переменные функции-родителя в их числе. это примерно тоже самое что и метод структуры/класса. только вместо класса - локальные переменные родителя. сейчас для того чтобы передать контекст, надо делать структуру, и ее передавать ссылкой. а вложенной функции, в паскале например, всей этой возни не нужно - даже затрат на передачу контекста нет, ибо контекст получается через стек.
    собственно по статье в вике https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BC
    "замыкание" и вложенная функция это одно и тоже.
    только тут есть один нюанс - замыкание в своем самом гибком варианте реализуемо в языках интерпретируемых. в компилирующем языке, реализовать такое поведение можно только тяжелыми костылями (поэтому досихпор замыканий нормальных и не было, если это не шаблоны). а вот вложенная функция - как раз легко реализуема, и без затрат по коду/производительности.

     

  • 1.16, Аноним (-), 12:39, 08/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    >  bugpron

    хехе, pron

     
  • 1.30, Аноним (-), 20:23, 08/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Правильно ли я понял, что теперь можно на лету компилировать C/C++ код и интерпретировать его?
     
     
  • 2.32, all_glory_to_the_hypnotoad (ok), 22:39, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    теперь это когда?
     
  • 2.33, Онаним (?), 22:55, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вот-вот, и я о том же подумал.
     
     
  • 3.36, Аноним (-), 23:01, 08/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    С другой стороны непонятно почему бы не взять Lua, Python или %любимый AST интерпретатор со своим GIL и другими удобствами% ?
     

  • 1.39, Аноним (-), 00:02, 09/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто-нибудь использует LLVM под Windows?  Я скачал официальные бинари clang, попробовал скомпилить свой проект. Компилит в 18 раз медленнее mingw, жуть какая-то. Может я что-то не так делаю? поделитесь успешным опытом.

    На Mac,FreeBSD такой херни не было, компилил шустро и даже быстрее gcc.

     
     
  • 2.50, Led (ok), 17:58, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Компилит в 18 раз медленнее mingw, жуть какая-то.

    Вендузятник должен страдать.

     

  • 1.40, Вареник (?), 05:24, 09/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Отлично! Нужная вещь. Ждемс в бэкпортах.
     
     
  • 2.43, Аноним (-), 07:39, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    http://apt.llvm.org/
     
     
  • 3.55, Вареник (?), 01:50, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > http://apt.llvm.org/

    Спасибо. Хотя их и так перекладывают в стандартные бэкпорты, но с задержкой.

     

  • 1.42, Аноним (-), 05:33, 09/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А при помощи Clang можно скомпилировать ядро Линукса? Невозможно! А вот, коллекция компиляторов GNU GCC может скомпилировать ядро Линукса. Да что там говорить, GNU GCC -- это основная компилирующая лошадка линуксоида.
     
     
  • 2.45, Аноним (-), 11:08, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Он не может компилировать только потому что разработчики ядра решили использовать по максимуму внутренние возможности gcc.
     
     
  • 3.54, Вареник (?), 01:48, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Скорей баги, чем возможности.
     
  • 2.46, Аноним (-), 15:25, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    если у разработчиков ядра - не хватает мозгов использовать только стандарт языка, а обязательно нужны GNU расширения - то кто им доктор ?
     
     
  • 3.51, пох (?), 18:18, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    gnu расширения в llvm в общем сохранены. Баги, из-за которых компилируется в принципе неправильный код - не все, поскольку это clean room разработка, и копирует только то, что либо документировано, либо удается легко обнаружить.
     
  • 2.53, Аноним (-), 23:21, 09/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Это называется вендорлок, чувак. Такая вот типасвобода.
     
  • 2.56, Аноним (-), 02:12, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А при помощи Clang можно скомпилировать ядро Линукса? Невозможно! А вот, коллекция
    > компиляторов GNU GCC может скомпилировать ядро Линукса. Да что там говорить,
    > GNU GCC -- это основная компилирующая лошадка линуксоида.

    А ядро фрибзди компилируется как шлангом, так и gcc. Какие нетривиальные выводы сделает из этого анонимный эксперт?

     
     
  • 3.57, пох (?), 19:53, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А ядро фрибзди компилируется как шлангом, так и gcc.

    а давно пробовали? А запустить скомпилированное? На x86 архитектуре?

    world WITHOUT_CLANG, насколько я знаю, сломан уже в 10.0


     
     
  • 4.58, Аноним (-), 21:31, 10/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> А ядро фрибзди компилируется как шлангом, так и gcc.
    > а давно пробовали? А запустить скомпилированное? На x86 архитектуре?

    А где-то с полгодика назад. И да, запустилось и проработало с пару неделек.
    > world WITHOUT_CLANG, насколько я знаю, сломан уже в 10.0

    Про мир я в курсе - обратите внимание на "ядро" в "ядро фрибзди".

     
     
  • 5.59, пох (?), 09:36, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Про мир я в курсе

    хотя, казалось бы - должно быть ровно наоборот - уж если где и быть подобным граблям, то уж никак не в коде bin/ls. Аднакаж...

    (специально для проспавших первый урок, которые щас набигут - нет, это не код плохой, это gcc в freebsd 4.2.1 2007го года, последний с еще не анально-огороженной лицензией, сейчас уже неудивительно, что люди перестают специально обращать внимание на совместимость с его багами)

     
     
  • 6.61, Аноним (-), 15:19, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Про мир я в курсе
    > хотя, казалось бы - должно быть ровно наоборот - уж если где
    > и быть подобным граблям, то уж никак не в коде bin/ls.
    > Аднакаж...

    LLVM. Не собирается шлангом.
    Ну и шланго-специфические опции типа -fsanitize=safe-stack, на которых спотыкается gcc.
    Или когда gcc упорно и не смотря на вполне правильно выглядящий -isystem= в env читает заголовочные файлы из /usr/local/include. Потом ... а потом мне надоело маяться этим самым.

     
     
  • 7.62, Аноним (-), 15:21, 11/09/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > LLVM. Не собирается GCC.
     
  • 7.64, пох (?), 13:48, 12/09/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > LLVM. Не собирается шлангом. [gcc'ем на самом деле]

    ну так у большинства, полагаю, WITHOUT для того и был, чтобы LLVM и не [пере]собирать - поскольку он плюсовый, то его пересборка даже на мощном ядре занимает дофига времени, процентов 80 от общего world, а не потому что мы за мир во всем мире и против проклятых проприетарастов.

    сейчас, увы, пользы от WITHOUT_CLANG/LLVM около нуля.

     

  • 1.65, adolfus (ok), 00:58, 14/09/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Поддержка расширения для использования сопрограмм в коде на C++ (пример кода).

    Ужас какой-то. Интересно посмотреть на код, который будет сгенрирован в результате.

     

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



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

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