The OpenNET Project / Index page

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

Новая версия набора компиляторов LLVM 3.3

18.06.2013 13:34

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

Новая версия примечательна интеграцией поддержки целевых платформ AArch64 и AMD R600 GPU, поддержкой систем IBM S390 на базе архитектуры z, значительным улучшением поддержки платформ PowerPC и MIPS. За счёт увеличение качества реализации автоматической векторизации циклов и реализации серии общих оптимизаций заметно увеличена производительность кода, генерируемого LLVM 3.3. В Clang доведена до готовности поддержка стандарта C++11, расширены возможности статического анализатора кода, добавлен инструментарий для автоматического преобразования кода C++ в вид, соответствующий спецификации C++11, подготовлено приложение для автоформатирования кода в vim и emacs.

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

  • Поддержка 64-разрядной архитектуры AArch64 (ARM64) в качестве целевой платформы. Архитектура AArch64 включает в себя новый набор команд A64, примечательный расширением числа регистров, новыми командами для вычислений с плавающей запятой (FP) и новыми векторными SIMD-инструкциями NEON. В настоящее время работа по реализации порта AArch64 ещё полностью не завершена, но уже поддерживается сборка приложений, написанных в соответствии со стандартами C99 и C++03, для платформы Linux.
  • Интеграция бэкэнда для использования в качестве целевой платформы GPU семейства R600 (HD2XXX - HD7XXX). Изначально бэкенд развивался в репозитории проекта Mesa, но был перенесён в кодовую базу LLVM. Бэкэнд необходим для компилятора шейдеров LLVM, который в свою очередь требуется для открытой реализации стандарта OpenCL;
  • Улучшено качество кода, генерируемого при использовании автоматической векторизации циклов (Loop Vectorizer), которая теперь включена по умолчанию при выборе режима оптимизации "-O3". В новой версии добавлена поддержка векторизации вызова функций, векторизации смешанных типов, частичного развёртывания кода в процессе векторизации, проверки указателей во время выполнения и т.д. Распараллеливание циклов позволяет заметно поднять производительность кода, генерируемого LLVM 3.3. В итоге независимые тесты производительности фиксируют более высокую производительность кода, собранного c использованием LLVM 3.3, по сравнению с LLVM 3.2;
  • Представлен новый SLP векторизатор, который пока не используется по умолчанию и требует для своего включения указания опции "-fslp-vectorize". Поддержка ранее доступного векторизатора BB сохранена и может быть активирована при указании опции "-fslp-vectorize-aggressive";
  • Значительно улучшена реализация бэкенда для процессоров PowerPC, в том числе поддержка наборов инструкций PowerPC 2.04/2.05/2.06 и обеспечение поддержки интегрированного ассемблера;
  • Улучшен бэкенд для архитектуры MIPS, добавлена поддержка инструментария Sourcery CodeBench, добавлены новые опции командной строки (-mxgot/-mno-xgot, -EL/-EB, -mmicromips/-mno-micromips, -msingle-float/-mdouble-float, -mabi=32 (o32 abi) и -mabi=64 (n64 abi)), улучшено качество генерации кода DSP-ASE;
  • Добавлен бэкенд SystemZ/s390x с поддержкой IBM z/Architecture;
  • Из состава удалён порт CellSPU и прекращена поддержка API для расширенной линковки на уровне промежуточного представления кода. В бэкенде для целевой платформы Hexagonv прекращена поддержка устаревших архитектур hexagonv2 и hexagonv3 (поддержка hexagonv4 и hexagonv5 сохранена).

Основные новшества субпроектов LLVM 3.3:

  • В компиляторе Clang полностью завершена реализация поддержки всех компонентов стандарта C++11, в том числе новых библиотек, таких как std::regex. В анонсе отмечается, что Clang является первым компилятором, поддерживающим в полной мере стандарт C++'11 (разработчики GCC выступали с похожим заявлением). Для упрощения миграции на C++11 в состав включен новый инструмент "C++'11 Migrator", позволяющий автоматически конвертировать код C++ в представление, использующее элементы C++11. Кроме того, в Clang 3.3 добавлена возможность использования символов Unicode в идентификаторах.

    В Clang Static Analyzer добавлены дополнительные проверки, позволяющие выполнять межпроцедурный статический анализ кода, выходящий за границы отдельных C++ конструкторов/деструкторов. Для разработчиков, использующих vim и emacs, представлено приложение clang-format, выполняющее функции интеллектуальной системы автоматического форматирования кода.

    В состав Clang включены патчи, необходимые для обеспечения сборки ядра Linux, что позволило приблизиться к состоянию, когда немодифицированное ядро Linux можно будет пересобрать штатным компилятором Clang. До сих пор для подобной сборки требовалось применение серии патчей, как к ядру, так и к Clang;

  • В DragonEgg, плагине к набору компиляторов GCC, заменяющем оригинальные оптимизаторы и генераторы кода GCC на аналоги, созданные в рамках проекта LLVM, добавлена поддержка GCC 4.8 (требуется gcc-4.8.1) и возможность записи объектных файлов с использованием встроенного ассемблера LLVM;
  • В отладчике LLDB добавлена поддержка точек наблюдения (watchpoints), представлен плагин для интеграции с Vim, улучшена поддержка регистров (в том числе векторных), реализована возможность отладки многопоточных программ, обеспечена сборка с использованием cmake/ninja/auto-tools/clang 3.3/gcc 4.6, добавлены новые команды для вывода процессов, присоединения к процессу и форка, реализована поддержка вычисления выражений;
  • Отмечен прогресс в реализации проекта Portable Computing Language OpenCL (PoCL), в рамках которого ведётся разработка полностью открытой реализации стандарта OpenCL, независимой от производителей графических ускорителей. PoCL позволит разработчикам не задумываться об особенностях той или иной реализации стандарта и использовать предоставляемые компилятором оптимизации вместо применения специфических для каждой платформы техник ручной оптимизации. PoCL реализован по модульному принципу, позволяющему использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;
  • Представлен проект Jade (Just-in-time Adaptive Decoder Engine), в рамках которого развивается универсальный движок для декодирования видео, использующих LLVM для JIT-компиляции адаптивных конфигураций декодера видео, определённых комитетом MPEG Reconfigurable Video Coding (RVC);
  • Обновлена реализация LDC - компилятора для языка программирования D, комбинирующего фронтэнд из состава эталонного компилятора D с бэкендом на базе LLVM, позволяющим генерировать эффективный нативный код. LDC поддерживает генерацию кода для систем x86/x86_64 Linux, Mac OS X и Windows, и PPC64 для Linux. В разработке находится создание генератора кода для архитектуры ARM.

Из параллельно развивающихся проектов, основанных на LLVM, можно отметить:

  • KLEE - символьный анализатор и генератор тестовых наборов;
  • Runtime-библиотека compiler-rt;
  • llvm-mc - автогенератор ассемблера, дизассемблера и других, связанных с машинным кодом компонентов, на основе описаний параметров LLVM-совместимых платформ.
  • VMKit - виртуальная машина для Java и .NET;
  • Реализация функционального языка программирования Pure;
  • LDC - компилятор для языка D;
  • Roadsend PHP - оптимизатор, статический и JIT компилятор для языка PHP;
  • Виртуальные машины для Ruby: Rubinius и MacRuby;
  • LLVM-Lua
  • FlashCCompiler - средство для компиляции кода на языке Си в вид пригодный для выполнения в виртуальной машине Adobe Flash;
  • LLDB - новая модульная инфраструктура отладки, использующая такие подсистемы LLVM как API для дизассемблирования, Clang AST (Abstract Syntax Tree), парсер выражений, генератор кода и JIT-компилятор. LLDB поддерживает отладку многопоточных программ на языках C, Objective-C и C++; отличается возможностью подключения плагинов и скриптов на языке Python; демонстрирует экстремально высокое быстродействие при отладке программ большого размера;
  • emscripten - компилятор биткода LLVM в JavaScript, позволяющий преобразовать для запуска в браузере приложения, изначально написанные на языке Си. Например, удалось запустить Python, Lua, Quake, Freetype;
  • sparse-llvm - бэкенд, нацеленный на создание Си-компилятора, способного собирать ядро Linux.
  • Portable OpenCL - открытая и независимая реализация стандарта OpenCL;
  • CUDA Compiler - позволяет сгенерировать GPU-инструкции из кода, написанного на языках Си, Си++ и Fortran;
  • Julia - открытый динамический язык программирования, использующий наработки проекта LLVM.


  1. Главная ссылка к новости (http://lists.cs.uiuc.edu/piper...)
  2. OpenNews: Проекту LLVM присуждена премия ACM Software System Award
  3. OpenNews: Новая версия набора компиляторов LLVM 3.2
  4. OpenNews: Портирование компилятора Clang для GNU/Hurd
  5. OpenNews: FreeBSD-CURRENT переведён по умолчанию на Clang
  6. OpenNews: В Clang доведена до готовности поддержка стандарта C++11 и приняты патчи для пересборки ядра Linux
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/37200-clang
Ключевые слова: clang, llvm, gcc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (123) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 14:05, 18/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Оптимизирует так круто, что даже бесконечный loop выполняется за пару секунд.
     
     
  • 2.6, Andrey (??), 14:55, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +7 +/
    бесконечный loop выполняется на пару секунд быстрее :)
     
     
  • 3.14, Аноним (-), 15:37, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > бесконечный loop выполняется на пару секунд быстрее :)

    В два раза быстрее!

     
     
  • 4.37, анон (?), 17:48, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –4 +/
    при значении бесконечности равном двум секундам
     
  • 3.44, IMHO (?), 20:04, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Мы все знаем, что Linux — это круто… он выполняет бесконечные циклы за 5 секунд.
    > Линус Торвальдс

    linux был первым кто выполнял бесконечные цыклы, наверное потому что программа падала в core )))

     
     
  • 4.48, Аноним (-), 20:20, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > linux был первым кто выполнял бесконечные цыклы,

    А что ваша система делает когда не озадачена? Грузит ящики бочками? :)

     
     
  • 5.57, anonymous (??), 21:27, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> linux был первым кто выполнял бесконечные цыклы,
    > А что ваша система делает когда не озадачена? Грузит ящики бочками? :)

    Перестукивается с серверами майкрософта.

     
  • 5.82, arisu (ok), 09:19, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> linux был первым кто выполнял бесконечные цыклы,
    > А что ваша система делает когда не озадачена? Грузит ящики бочками? :)

    вин9x, например, любила странички в свопе перекладывать. нет, серьёзно.

     
     
  • 6.108, Аноним (-), 15:38, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > странички в свопе перекладывать

    Пасьянс?

     

  • 1.2, Аноним (-), 14:19, 18/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > В компиляторе Clang полностью завершена реализация поддержки всех компонентов стандарта C++11, в том числе новых библиотек, таких как std::regex. В анонсе отмечается, что Clang является первым компилятором, поддерживающим в полной мере стандарт C++'11

    Они теперь в каждом релизе будут это заявлять?

     
     
  • 2.4, BayaN (ok), 14:38, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Они теперь в каждом релизе будут это заявлять?

    А они это заявляли в предыдущем релизе? По-моему прошлая новость относилась к ветке 3.3 из которой как раз и отпочковался этот релиз.


     
  • 2.10, Аноним (-), 15:16, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ага :)
     
  • 2.12, Аноним (-), 15:34, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    "В компиляторе Clang полностью завершена реализация поддержки всех компонентов стандарта C++11, в том числе новых библиотек, таких как std::regex. В анонсе отмечается, что Clang является первым компилятором, поддерживающим в полной мере стандарт C++'11"

    > Они теперь в каждом релизе будут это заявлять?

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

     
     
  • 3.24, arisu (ok), 16:51, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну наверное до тех пор, пока не появится другой такой компилятор, в
    > отношении которого можно будет заявить то же самое.

    боюсь, что не появится никогда. как может появиться ещё один компилятор, которы «первый в полной мере поддерживает», если один уже есть?

     
     
  • 4.41, Очередной Анонимус (?), 17:59, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > как может появиться ещё один компилятор, которы «первый в полной мере поддерживает», если один уже есть?

    Проблема в том, что таких «первых» уже два.

     
     
  • 5.52, Аноним (-), 20:29, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    При том у обоих чего-нибудь да не хватает. Но пузомерка зато уже о-го-го :)
     
  • 5.70, arisu (ok), 08:57, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> как может появиться ещё один компилятор, которы «первый в полной мере поддерживает», если один уже есть?
    > Проблема в том, что таких «первых» уже два.

    FIGHT!

     
  • 2.13, Аноним (-), 15:36, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Они теперь в каждом релизе будут это заявлять?

    Будут. И правильно.
    Разработчикам gcc очень не хватает хорошего пинка под зад, чтобы прекратить мастурбировать и начать работать.

     
     
  • 3.26, Аноним (-), 16:55, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Разработчикам gcc очень не хватает хорошего пинка под зад, чтобы прекратить мастурбировать
    > и начать работать.

    У разработчиков GCC кодогенерация уже намного лучше чем в шланге. Особенно если посмотреть на всякие там ARM и MIPS, где шланг вообще генерит нечто жуткое, а зачастую и просто глючное. А то что начиная с некоего момента сильно оптимизировать становится намного труднее - так это логично.

    Легко ускорить в 2 раза паршивый кодогенератор. А вот ускорить в 2 раза близкий к оптимальному кодогенератор - уже ой. Что логично.

     
     
  • 4.68, linux must __RIP__ (?), 08:32, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > У разработчиков GCC кодогенерация уже намного лучше чем в шланге. Особенно если посмотреть на всякие там ARM и MIPS, где шланг вообще генерит нечто жуткое, а зачастую и просто глючное. А то что начиная с некоего момента сильно оптимизировать становится намного труднее - так это логично.

    Мы еще помним когда ядро собранное gcc отказывалось грузиться на x86. А вы не помните этого ?

     
  • 3.31, arisu (ok), 17:01, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ты, без сомнения, можешь подробно рассказать, что именно тебя не устраивает в gc... большой текст свёрнут, показать
     
     
  • 4.39, анон (?), 17:51, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а как на нём писать, если он не поддерживается?
     
     
  • 5.75, arisu (ok), 09:02, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а как на нём писать, если он не поддерживается?

    кем?

     
  • 5.91, Аноним (-), 10:11, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    На чём?
     
  • 4.43, Andrew Kolchoogin (ok), 19:36, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > ты, без сомнения, можешь подробно рассказать, что именно тебя не устраивает в gcc
    > и над чем стоило бы поработать.

    Об этом могут рассказать сами разработчики LLVM: http://llvm.org/docs/GettingStarted.html#broken-versions-of-gcc-and-other-too

    Из версии в версию у GCC грабли и баги.

     
     
  • 5.77, arisu (ok), 09:04, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Об этом могут рассказать сами разработчики LLVM: http://llvm.org/docs/GettingStarted.html#broken-versions-of-gcc-and-other-too
    > Из версии в версию у GCC грабли и баги.

    отличная ссылка. прелестная просто. хорошо иллюстрирует отсутствие мозга у фанбоев llvm и у бздешников в частности.

     
     
  • 6.88, Andrey Mitrofanov (?), 09:52, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Об этом могут рассказать сами разработчики LLVM: http://llvm.org/docs/GettingStarted.html#broken-versions-of-gcc-and-other-too
    >> Из версии в версию у GCC грабли и баги.
    > отличная ссылка. прелестная просто. хорошо иллюстрирует отсутствие мозга у фанбоев llvm
    > и у бздешников в частности.

    Угу. Штаб-квартира рассказала Кольчугину, чем _его не устраивает GCC. Чем его не устраивает LLVM штаб-квартира не рассказала -- вывод очевиден! LLVM чудо как устраивает Кольчугина. ---Желееезные нервы, трусца.

     
  • 4.61, Аноним (-), 23:06, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > нет, поддержка цыпыпыадынадын — не интересует.

    Не интересует функциональность компилятора, интересует функциональность мастурбатора? Проход, не задерживайся.

     
     
  • 5.76, arisu (ok), 09:03, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> нет, поддержка цыпыпыадынадын — не интересует.
    > Не интересует функциональность компилятора, интересует функциональность мастурбатора?
    > Проход, не задерживайся.

    сколько и какого софта *ты лично* написал на адынадын? без каких его фич, которые не реализваны в gcc, ты не можешь жить? вангую, что внятного ответа не будет. зато поорать про «поддержку и развитие» — завсегда готов, не так ли?

     
     
  • 6.109, 0xd34df00d (ok), 18:01, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С выходом gcc 4.8 жаловаться действительно (почти) не на что.

    Только вот поддержка бажная — например, в 4.7 (который до сих пор в продакшене), есть довольно стремный баг, когда нельзя захватить лямбду в другую лямбду по значению, если другая лямбда используется в списке инициализации. Кое-какие проблемы с шаблонами есть.

    Впрочем, в clang тоже багов хватает, и даже поболе, чем в gcc.

    Не буду, впрочем, упоминать софт, который я на 11 пишу.

     
     
  • 7.111, arisu (ok), 18:29, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    я ж у анонимуса спрашивал, а не у человека, который действительно код пишет.

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

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

    > Кое-какие проблемы с шаблонами есть.

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

     
     
  • 8.112, 0xd34df00d (ok), 18:36, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Причина 8212 в одном gcc изме, как который парсится такая лямбда Правда, я g... большой текст свёрнут, показать
     
     
  • 9.113, arisu (ok), 18:58, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ТЫ ЗНАЛ а также помогают писать неподдерживаемый код пардон, книга Александрес... текст свёрнут, показать
     
     
  • 10.115, 0xd34df00d (ok), 19:00, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Книга на китайском для меня тоже не очень отличается от какого-нибудь произведен... текст свёрнут, показать
     
     
  • 11.116, arisu (ok), 19:14, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    применить можно почти любую фигню, но фигнёй-то от этого она быть не перестаёт, ... текст свёрнут, показать
     
  • 11.117, arisu (ok), 19:14, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    p s Александреску-то не зря на D убежал 3... текст свёрнут, показать
     
  • 9.114, arisu (ok), 18:59, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    p s а всякие генераторы и прочее пишутся на DSL который потом при необходимост... текст свёрнут, показать
     
  • 2.18, Andrey Mitrofanov (?), 15:52, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +10 +/
    >>первым компилятором, поддерживающим в полной мере стандарт C++'11
    > Они теперь в каждом релизе будут это заявлять?

    Ты не понял _тонкого _слегка рекурсивного юмора автора *этих* новостей:

    Почувствуй переход от полной _цены к полной _мере, переход первого места от конкурсанта к конкурсанту! Чувствуешь? Чувствуешь!!?


    18.06.2013 13:34  Новая версия набора компиляторов LLVM 3.3
    ...отмечается, что Clang является первым компилятором, поддерживающим в полной мере стандарт C++'11 (разработчики GCC выступали с похожим заявлением)

    31.05.2013 23:20  Обновление набора компиляторов GCC 4.8.1
    ...сделало G++ первым компилятором C++, реализовавшим все значительные возможности стандарта C++11


    20.04.2013 23:45  В Clang доведена до готовности поддержка стандарта C++11
    ...полностью завершена реализация поддержки всех компонентов стандарта C++11. Статус полной совместимости с C++11 был достигнут ... Примечательно, что проектом GCC реализация стандарта C++11 [I]ещё не завершена[/I].

    21.12.2012 14:23  Новая версия набора компиляторов LLVM 3.2
    ...Clang обеспечена полноценная поддержка стандарта C++'11.

     
  • 2.49, Аноним (-), 20:20, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Они теперь в каждом релизе будут это заявлять?

    И, главное, опять соврали - ниже перечислено то чего не хватает.

     

  • 1.3, Главные Редакторы (ok), 14:33, 18/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Главное преимуществ LLVM в скорости компиляции. Но это нужно только программисту пишущему программу, для программистов живущих в сферическом вакууме и создающих уникальные "вещи сами в себе" с точки зрения архитектуры и элегантности найденных решений. Кто вычислит взаимосвязь между скоростью компиляции и временем необходимым для создания программы?
     
     
  • 2.5, BayaN (ok), 14:43, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Главное преимуществ LLVM в скорости компиляции.

    Ты зря стесняешься, сходи по ссылке http://llvm.org/ - там тебе расскажут в чем преимущества и зачем оно нужно.


     
     
  • 3.9, Хрен с горы (?), 15:09, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И заодно Apple Developers Kit предложат за недорого?
     
     
  • 4.15, Аноним (-), 15:37, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > И заодно Apple Developers Kit предложат за недорого?

    Вы так говорите, как будто это что-то плохое.

     
     
  • 5.28, Аноним (-), 16:56, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вы так говорите, как будто это что-то плохое.

    Грeбля под одну контору - да, это плохое. Это вендорлоком попахивает.

     
     
  • 6.53, anonymus (?), 21:18, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Intel, AMD, ARM, Qualcom, MIPS (part of Imagination Technologies), как-то слишком много названий у одной конторы.
     
     
  • 7.59, anonymus (?), 21:48, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ах да, и всеми вами любимый Google, и немного IBM.
     
  • 7.63, Аноним (-), 23:12, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Intel, AMD, ARM, Qualcom, MIPS (part of Imagination Technologies), как-то слишком много названий у одной конторы.

    Контора зовется Apple, а те, кого ты перечислил - это свадебные генералы.

     
     
  • 8.65, anonymus (?), 23:15, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Таким образом, разработчики из этих компаний, которые коммитят код в LLVM просто... текст свёрнут, показать
     
     
  • 9.74, arisu (ok), 09:01, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    примерно так, да ... текст свёрнут, показать
     
     
  • 10.90, anonymus (?), 10:02, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Финансы, подсказывают мне, что если бы эти работы не окупались в перспективе, то... текст свёрнут, показать
     
     
  • 11.101, arisu (ok), 12:15, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а ты 8212 русский ... текст свёрнут, показать
     
     
  • 12.105, anonymus (?), 12:54, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чистая приведенная стоимость ЧПС , тебе нравится больше ... текст свёрнут, показать
     
     
  • 13.106, Andrey Mitrofanov (?), 13:46, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    MBA-спиик в любом виде _не лучше ... текст свёрнут, показать
     
  • 13.107, arisu (ok), 14:08, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    мне без разницы, я намекал, что запятая лишняя ... текст свёрнут, показать
     
  • 6.64, Аноним (-), 23:12, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Это вендорлоком попахивает.

    Ты так говоришь, как будто это что-то плохое.

     
  • 4.16, Аноним (-), 15:39, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Противники LLVM после каждой новости о нем, с очередным достижением, в очередной раз в чем-то утираются, и каждый раз что-то злобно квакают не в тему.
     
     
  • 5.19, Аноним (-), 16:12, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А яблофилы громко об этом кричат :)
     
  • 5.20, Аноним (-), 16:16, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Противники LLVM

    У LLVM нет противников.

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

     
     
  • 6.21, Аноним (-), 16:19, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Есть только здравомыслящие люди, которые настороженно относятся к использованию в опенсорсе технологии, полностью контролируемой известной проприетарной компанией.

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

     
  • 6.27, arisu (ok), 16:55, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Противники LLVM
    > У LLVM нет противников.
    > Есть только здравомыслящие люди, которые настороженно относятся к использованию в опенсорсе
    > технологии, полностью контролируемой известной проприетарной компанией.

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

    а проект, тем не менее, очень достойный. и как минимум один из его плюсов — это конкуренция с gcc. потому что без конкурентов разработчики могут и забить: «всё равно мы единственные, а потому — лучшие».

    хотя вот идиотскую caret, которую впилили в gcc 4.8 — так лучше бы забили.

     
     
  • 7.29, Аноним (-), 16:57, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > у тебя что, исходники отберут, что ли? даже если и закроют новые
    > версии, старые наработки отстанутся.

    Ну да. Вот только как ты относишься к всяким некрофагам, уцепившимся за gcc 2.95 или 4.2 накрайняк? Вот ты будешь вообще проверять как твоя программа билдуется в gcc 2.95? :)

     
     
  • 8.33, arisu (ok), 17:08, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    на 4 6 приходилось хреново билдится 3... текст свёрнут, показать
     
     
  • 9.47, Аноним (-), 20:17, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    По сравнению с перспективой билдить 4 2 который умеет валиться с internal error... текст свёрнут, показать
     
     
  • 10.73, arisu (ok), 09:00, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    но использовали же -O0 наш друг, если что ... текст свёрнут, показать
     
  • 6.35, Клыкастый (ok), 17:43, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Код открыт. Форкни - контролируй сам.
     
     
  • 7.46, Аноним (-), 20:13, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Код открыт. Форкни - контролируй сам.

    - А 20 гопников могут дать мне в табло...
    - Но ты же тоже можешь дать в лицо 20 гопникам! Все честно!

     
     
  • 8.87, Клыкастый (ok), 09:52, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Во как Оказывается GPL уже не работает ... текст свёрнут, показать
     
     
  • 9.94, Andrey Mitrofanov (?), 10:32, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Работает Требуй у 20 гопников, давших тебе в лицо, передать тебе также все исхо... текст свёрнут, показать
     
  • 7.62, Аноним (-), 23:11, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Код открыт. Форкни - контролируй сам.

    udev уже как-то форкнули. Можно не напоминать, чем это закончилось?
    Помимо желания форкать, нужна еще и квалификация.

    И авторитет. Если Вася Пупкин форкнет LLVM и начнет запиливать фичи, а яббл начнет запиливать свои (не спеша делиться кодом) - чьими фичами будут пользоваться в 99.99999% проектов?

     
     
  • 8.69, linux must __RIP__ (?), 08:54, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    давайте начнем разделять - что Apple просто спонсирует разработку Вам никто не ... текст свёрнут, показать
     
     
  • 9.71, Аноним (-), 08:58, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а сутенер просто спонсирует благродных дам ... текст свёрнут, показать
     
     
  • 10.92, Клыкастый (ok), 10:17, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    страшно представить, как выглядит GPL в таких аналогиях ... текст свёрнут, показать
     
     
  • 11.95, Andrey Mitrofanov (?), 10:34, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сутенёры предоставляют справку из докома о том, что они являются полностью ориги... текст свёрнут, показать
     
     
  • 12.97, Клыкастый (ok), 10:54, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не разочаровал ... текст свёрнут, показать
     
  • 8.89, Клыкастый (ok), 09:55, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так внезапно выяснится, что GPL не спасает дважды выяснится И вдруг выясн... текст свёрнут, показать
     
     
  • 9.96, Andrey Mitrofanov (?), 10:41, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С чего ты взял, что _GPL_ должна скасать от отсутствия квалификации и как-то пом... текст свёрнут, показать
     
     
  • 10.98, Клыкастый (ok), 10:57, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я это жплботы тут верещат, что gpl от всех напастей Код открыт Подключай свою... текст свёрнут, показать
     
  • 6.67, Аноним (-), 00:36, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Противники LLVM
    > У LLVM нет противников. Есть только здравомыслящие люди, которые настороженно относятся к использованию в опенсорсе технологии, полностью контролируемой известной проприетарной компанией.

    Это называется - "Я не трус, но я боюсь" (С).

     
  • 3.50, Аноним (-), 20:22, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > чем преимущества и зачем оно нужно.

    Ага, ты еще предложи на сайте майкрософта преимущества винды смотреть. А это карманный проектик эппла, который по маркетинговому буллшиту спец великий.

     
     
  • 4.54, anonymus (?), 21:20, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> чем преимущества и зачем оно нужно.
    > Ага, ты еще предложи на сайте майкрософта преимущества винды смотреть. А это
    > карманный проектик эппла, который по маркетинговому буллшиту спец великий.

    Ага, а так же карманный проектик Intel, AMD, Qualcom, ARM, MIPS...

     
     
  • 5.78, Аноним (-), 09:04, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>> чем преимущества и зачем оно нужно.
    >> Ага, ты еще предложи на сайте майкрософта преимущества винды смотреть. А это
    >> карманный проектик эппла, который по маркетинговому буллшиту спец великий.
    > Ага, а так же карманный проектик Intel, AMD, Qualcom, ARM, MIPS...

    чтро за бред? У Intel - ICC, у AMD open64.

     
     
  • 6.83, anonymus (?), 09:37, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, а драйвер Intel OpenCL использует LLVM, HSA компилятор от AMD использует LLVM. nVidia использует LLVM для CUDA.
     
     
  • 7.118, Аноним (-), 01:40, 20/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Угу, а драйвер Intel OpenCL использует LLVM,

    И где у интеля LLVM в драйвере? И где, собственно. сам драйвер с opencl? Им все ипут на этот счет мозг, но готового результата нет.

     
  • 2.7, обычный программист (?), 14:56, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Главное преимуществ LLVM в скорости компиляции.

    В свое время я это проверял,
    взял свой проект(c++), благо там билд система основана на cmake,
    и собрал с помощью clang и gcc, время было практически одинаково: 1 мин 40 сек на 4 ядерном проце +- 5 сек,
    так что с учетом того, что и код он оптимизирует похуже использовать его не вижу смысла.

     
     
  • 3.110, 0xd34df00d (ok), 18:07, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Во-первых, на богатом темплейтами коде clang из svn месячной давности c -O2 у меня компилирует куда шустрее, чем gcc 4.7 с -O2, процентов на 20. Правда, тут уже смотреть надо, что именно включает -O2 для каждого из компиляторов.

    Во-вторых, у clang куда понятнее сообщения об ошибках, это надо признать. Особенно с теми же темплейтами. Даже gcc 4.7 пока еще не сравнится (4.8 не пробовал, впрочем).

     
  • 2.8, Аноним (-), 15:03, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Главное преимуществ LLVM в скорости компиляции.

    Преимущество LLVM перед чем? Может, ты имел в виду "преимущество clang перед gcc и g++"? Так новость не о нём вообще-то, а об LLVM. Если говорить о преимуществах LLVM перед GCC (который GNU Compiler Collection, а не GNU C Compiler), как минимум одно очевидно — GCC нельзя использовать в качестве JIT-компилятора, в отличии от.

     
     
  • 3.23, freehck (ok), 16:32, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Если, конечно, считать это преимуществом.
     
     
  • 4.32, Аноним (-), 17:03, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Если, конечно, считать это преимуществом.

    Иногда это может и преимуществом быть. Но очень нишевым. Ну да, из GCC неудобно делать генерилку кода для GPU, а самолично писать парсер opencl-ного диалекта си может и подзадолбать. Вот где-то там оно даже осмысленно. Хотя даже там с ним амд намучались по полной программе, с превышением.

     
  • 2.25, arisu (ok), 16:53, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    вообще-то одно из нехилых преимуществ *llvm* в том, что это очень неплохая библиотека для jit- и aot- компиляции, которую можно встраивать в свои проекты. а так — я не знаю, пишет ли кто-то вручную на ассемблере llvm. вряд ли.

    а clang — это немного другой проект, вообще-то.

     
     
  • 3.30, Аноним (-), 17:01, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > вообще-то одно из нехилых преимуществ *llvm* в том, что это очень неплохая
    > библиотека для jit- и aot- компиляции, которую можно встраивать в свои проекты.

    Кстати да, как портабельная генерилка кода для всяких там GPU и прочая - ну вроде нормально смотрится. Если разовьется до достойного уровня как кодогенератор представляющий ценность - так оно и к gcc через плагины привинчивается. Другое дело что качество кодогенерации там оставляет желать и смысл этим пользоваться - в районе нуля.

     
     
  • 4.55, anonymus (?), 21:24, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> вообще-то одно из нехилых преимуществ *llvm* в том, что это очень неплохая
    >> библиотека для jit- и aot- компиляции, которую можно встраивать в свои проекты.
    > Кстати да, как портабельная генерилка кода для всяких там GPU и прочая
    > - ну вроде нормально смотрится. Если разовьется до достойного уровня как
    > кодогенератор представляющий ценность - так оно и к gcc через плагины
    > привинчивается. Другое дело что качество кодогенерации там оставляет желать и смысл
    > этим пользоваться - в районе нуля.

    А будет пример тестов (кроме OpenMP) в которых Clang/LLVM, DragonEgg/LLVM, сильно проигрывают GCC?

     
     
  • 5.72, arisu (ok), 08:59, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А будет пример тестов (кроме OpenMP) в которых Clang/LLVM, DragonEgg/LLVM, сильно проигрывают
    > GCC?

    да запросто. берём MIPS. собираем что-нибудь при помощи gcc. запускаем. собираем что-нибудь… wait! oh, shi~~~

     
     
  • 6.84, anonymus (?), 09:41, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы лично работаете с MIPS? Или ARM, в крайнем случае?

    Хотите пользоваться GCC пользуйтесь, или кто-то не дает? А орать, что что-то не нужно, по причине, что оно вам не нравится, не стоит

     
     
  • 7.93, Клыкастый (ok), 10:20, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Хотите пользоваться GCC пользуйтесь, или кто-то не дает? А орать, что что-то
    > не нужно, по причине, что оно вам не нравится, не стоит

    arisu тут один из немногих вменяемых, который не орёт "не надо". пройдитесь по треду.

     
  • 7.100, arisu (ok), 12:13, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А орать, что что-то не нужно, по причине, что оно вам не нравится, не стоит

    и где я орал «не нужно»? ты попросил показать, когда clang/llvm сильно проигрывает. я показал: проигрыш бесконечен. с чего ты решил, что это равносильно «не нужно» — я не знаю.

     
  • 5.119, Аноним (-), 01:45, 20/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ага, сразу отмазки начались - видио вы в курсе что в ряде проектов слив в разы ... большой текст свёрнут, показать
     
     
  • 6.123, Алексей (??), 10:59, 21/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> А будет пример тестов (кроме OpenMP)
    > Ага, сразу отмазки начались - видио вы в курсе что в ряде
    > проектов слив в разы :)

    На самом деле все из-за того, что OpenMP доступен не под gpl только для GCC:
    http://habrahabr.ru/post/184096/

     
  • 6.124, anonymus (?), 17:03, 21/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А как это происходит в Open64, или в другом многоархитектурном компиляторе?
     

  • 1.17, ILoveMicrosoft (ok), 15:44, 18/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > CUDA Compiler - позволяет сгенерировать GPU-инструкции из кода, написанного на языках Си, Си++ и Fortran;

    Не понял, безотносительно к типу GPU (производителю)?

     
     
  • 2.22, ананим (?), 16:29, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да, если этот производитель nvidia.

    зыж
    по ссылке уже что ли шлёпнул бы.
    а там и комменты почитал.

     

  • 1.34, lucentcode (ok), 17:31, 18/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    LLVM развивается в нужную сторону. Скоро он станет отличной альтернативой GCC, даже для сборки Linux. Интересно, какой дистрибутив первым наладит процесс сборки с использованием сабжа?
     
     
  • 2.36, iZEN (ok), 17:45, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > LLVM развивается в нужную сторону. Скоро он станет отличной альтернативой GCC, даже
    > для сборки Linux.
    > Интересно, какой дистрибутив первым наладит процесс сборки с использованием сабжа?

    FreeBSD давно уже собирается LLVM/Clang, а линуксу нужны какие-то нанотехнологичные патчи в самом LLVM/Clang и в своих исходниках.


     
     
  • 3.40, анон (?), 17:55, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > давно уже собирается

    я давно уже собираюсь стать миллиардером

     
     
  • 4.60, Аноним (-), 22:15, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Очки протри. Уже собирается, а не собирается начать собираться.
     
  • 3.80, arisu (ok), 09:12, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    всё, линуксокапец пришёл!
     
  • 2.51, Аноним (-), 20:26, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Скоро он станет отличной альтернативой GCC,

    ...и под всякую эмбедовку нас опять начнут пичкать проприетарными SDK? Спасибо, это мы уже проходили. Добавки не надо. Корпорасты - это такие существа, которым дай волю и они термоядерные ковровые бомбардировки учинят. Если это сулит профит.

    > Интересно, какой дистрибутив первым наладит процесс сборки с использованием сабжа?

    Гента какая-нибудь, которым вечно дурь разработчиковскую девать некуда.

     
  • 2.56, anonymus (?), 21:26, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > LLVM развивается в нужную сторону. Скоро он станет отличной альтернативой GCC, даже
    > для сборки Linux. Интересно, какой дистрибутив первым наладит процесс сборки с
    > использованием сабжа?

    Debian, где-то была новость, что они собрали 80%, или больше своего репозитория, кроме ядра.

     

  • 1.38, Аноним (-), 17:49, 18/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Для разработчиков, использующих vim и emacs, представлен плагин "Clang Format", выполняющий функции интеллектуальной системы автоматического форматирования кода."

    clang-format - это не плагин для вима с емаксом, а отдельная программа, выдающая отформатированный код в stdout

     
  • 1.42, valexey (?), 18:30, 18/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > В компиляторе Clang полностью завершена реализация поддержки всех
    > компонентов стандарта C++11, в том числе новых библиотек, таких как std::regex.

    Врут.

    Не реализовано:
    1) Minimal support for garbage collection and reachability-based leak detection
    2) Abandoning a process and at_quick_exit
    3) Extended integral types

     
     
  • 2.45, Аноним (-), 20:12, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а что вы ожидали от эппла? Громкий маркетинговый буллшит - штука такая.
     
     
  • 3.58, anonymus (?), 21:45, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну а что вы ожидали от эппла? Громкий маркетинговый буллшит - штука
    > такая.

    А может расскажешь нам, как компилятор может брать на себя работу стандартной библиотеки в случае at_quick_exit, или зачем делать "reachability-based leak detection," если уже есть инструмент основаный на LLVM, который реализует данную функциональность? От Apple там только 5 разработчиков, все остальное из других компаний индустрии.

     
     
  • 4.66, valexey (?), 23:49, 18/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Стандартная библиотека это часть языка. И у clang она своя. Это раз.

    Два - они же в анонсе хвастают в том числе и фичами стандартной библиотеки, например тем же std::regex.

    Три - "reachability-based leak detection" нужен просто потому, что он есть в стандарте. Без него реализация не полна.

     
  • 4.81, arisu (ok), 09:15, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    затем, чтобы не врать в заявлении о «полной реализации всех компонентов стандарта». если что-то не сделано, то это никак не «полная реализация». усёк?
     
     
  • 5.85, anonymus (?), 09:43, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если что-то не нужно делать, его не нужно делать.

    И, arisu, меньше яду...

     
     
  • 6.102, arisu (ok), 12:18, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если что-то не нужно делать, его не нужно делать.

    вот именно. если полной реализации нет — не нужно писать, что она есть.

     
  • 4.120, Аноним (-), 01:48, 20/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А может расскажешь нам, как компилятор может брать на себя работу стандартной
    > библиотеки в случае at_quick_exit,

    Внезапно, стандартная либа обычно с компилером поставляется. Или где-то рядом.

    > или зачем делать "reachability-based leak detection,"

    Хорошая отмазка - "это не нyжно, так яппл сказал" :). Так, а что там еще посчитали "лишним" в погоне за маркетинговым буллшитом? :)

    > От Apple там только 5 разработчиков,

    При том clang только они и пилят по сути. А остальные - ну да, там LLVM всякий пилят и что еще.

     

  • 1.79, arisu (ok), 09:07, 19/06/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    они уже запилили поддержку nested functions и http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html ? или для qsort надо по-прежнему писать отдельную функцию, которой даже параметр не передашь?
     
     
  • 2.86, anonymus (?), 09:46, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > они уже запилили поддержку nested functions и http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
    > ? или для qsort надо по-прежнему писать отдельную функцию, которой даже
    > параметр не передашь?

    GNU C не является стандартом, и если вам нужно используйте, более человеко любивые языки

     
     
  • 3.99, BayaN (ok), 11:56, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >GNU C не является стандартом

    Он очень туда просится, но в комитете к сожалению одни наркоманы.

     
  • 3.103, arisu (ok), 12:25, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > GNU C не является стандартом

    но это ни разу не причина не использовать удобства, оным предлагаемые. то, что в комитете по стандартизации сидят дауны — тем более не причина. особенно это не причина не реализовывать удобства. ибо две вещи, которые я назвал, при скрещивании дают офигенно удобные лямбды.




    #define lambda(_return_type, _body_and_args) ({ \
      _return_type __fn__ _body_and_args \
      __fn__; \
    })

    ...
    int ascending;
    ...
    qsort(array, 42, sizeof (int), lambda (int, (const void *a, const void *b) { return (ascending ? (*(int*)a)-(*(int*)b) : (*(int*)b)-(*(int*)a)); }));


    разве не красота? особенно если учесть, что лямбда имеет доступ к переменным функции-родителя, как это показано в коде выше. понятно, что пример синтетический, первая придуманая иллюстрация.

    и да, я это активно использую. именно потому, что удобно. я не прочь сравнивать gcc и clang/llvm, но последний никак не может собрать мой софт. пичалечка.

     
     
  • 4.121, Аноним (-), 01:50, 20/06/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > разве не красота? особенно если учесть, что лямбда имеет доступ к переменным
    > функции-родителя, как это показано в коде выше. понятно, что пример синтетический,
    > первая придуманая иллюстрация.

    Хм, симпатичненько.

     
  • 3.104, arisu (ok), 12:27, 19/06/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да и вообще, nested functions весьма способствуют удобной и красивой организации кода без геморроя с передачей кучи параметров и без загаживания namespace. макросы не предлагать, это ужос-ужос-ужос.
     

  • 1.125, iZEN (ok), 10:51, 08/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Обновился:
    % cc --version
    FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
    Target: x86_64-unknown-freebsd9.1
    Thread model: posix
     

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



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

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