The OpenNET Project / Index page

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

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

28.02.2015 00:09

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

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

  • Применяемый по умолчанию режим языка Си изменён с C99 с расширениями GNU на C11 с расширениями GNU;
  • Добавлена экспериментальная поддержка некоторых элементов будущего стандарта C++1z (C++17), в том числе выражения Fold, символьного литерала u8, краткого определения вложенных пространств имён (namespace A::B { ... } вместо namespace A { namespace B { ... } }), атрибутов для пространств имён;
  • Добавлена поддержка стандартного C11-заголовка stdatomic.h;
  • Встроенный макрос __has_attribute больше не выполняет проверку атрибутов с учётом различных синтаксисов (GNU, C++11, __declspec и т.п.) и ограничивается только запросом атрибутов в стиле GNU. Для запросов атрибутов в стилях C++11 и __declspec следует использовать отдельные макросы __has_cpp_attribute и __has_declspec_attribute;
  • В утилите clang-format обеспечена возможность форматирования кода на языке Java;
  • Средства диагностики расширены возможностями по выявлению новых типов ошибок. Реализован механизм умной корректировки опечаток;
  • Изменена логика установки макроса __EXCEPTIONS, который теперь привязывается к включению исключений как для C++, так и для Objective-C. Для надёжной проверки включения исключений для C++ следует кроме проверки __EXCEPTIONS также проверять и __has_feature(cxx_exceptions);
  • Добавлены новые директивы "#pragma unroll" и "#pragma nounroll", позволяющие управлять оптимизацией по развёртыванию циклов;
  • Значительно улучшена поддержка платформы Windows. Достигнут уровня самопересборки (self host) в окружении msvc на x86 и x64 системах Windows. Кроме исключений, поддержка Microsoft C++ ABI более-менее полностью реализована;
  • Продолжена реализация поддержки OpenMP, добавлены дополнительные семантики pragma, определённые в стандарте OpenMP 3.1. Runtime-библиотека OpenMP адаптирована для архитектур ARM и PowerPC. Улучшена совместимость с GCC 4.9;

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

  • В состав включен набор биндингов для обеспечения поддержки развиваемого компанией Google языка программирования Go, который позиционируется как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Принятый код основан на наработках проекта LLVM Go, разработчики которого согласились перелицензировать код под лицензией LLVM и предложили свою работу для включения в основной состав LLVM. Включение биндингов в состав LLVM является необходимым условием дальнейшей интеграции в LLVM фронтэнда с компилятором для языка Go (llgo), который построен с использованием данных биндингов.
  • Проект LLVMLinux достиг уровня, при котором возможна пересборка ядра Linux штатным компилятором Clang c применением к ядру небольшого числа патчей. В новом выпуске добавлены опции "-mabicalls" "-mno-abicalls", устранены проблем с совместимостью inline-ассемблера LLVM и GCC, во встроенный ассемблер добавлена поддержка директив, используемых в коде ядра Linux;
  • Поддержка интеграции LLVM IR в обычные объектные файлы. В частности, биткод теперь может быть размещён внутри специальной секции .llvmbc в составе обычных объектных файлов ELF, COFF и Mach-O;
  • Требования к минимально поддерживаемой версии Python повышены до выпуска 2.7;
  • Удалён код старого JIT-компилятора, всем пользователям рекомендуется перейти на MCJIT;
  • Прекращена поддержка платформы AuroraUX;
  • Реализована возможность преобразования доступного в MSVC вызова __vectorcall в вызов x86_vectorcallcc;
  • Добавлен новый экспериментальный механизм для описания точек сохранения (safepoint) в сборщике мусора;
  • Отмечен прогресс в реализации проекта Portable Computing Language OpenCL (PoCL), в рамках которого ведётся разработка полностью открытой реализации стандарта OpenCL, независимой от производителей графических ускорителей. PoCL позволит разработчикам не задумываться об особенностях той или иной реализации стандарта и использовать предоставляемые компилятором оптимизации вместо применения специфических для каждой платформы техник ручной оптимизации. PoCL реализован по модульному принципу, позволяющему использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;

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

  • KLEE - символьный анализатор и генератор тестовых наборов;
  • Runtime-библиотека compiler-rt;
  • llvm-mc - автогенератор ассемблера, дизассемблера и других связанных с машинным кодом компонентов на основе описаний параметров LLVM-совместимых платформ.
  • Реализация функционального языка программирования 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.
  • Jade (Just-in-time Adaptive Decoder Engine) - универсальный движок для декодирования видео, использующий LLVM для JIT-компиляции адаптивных конфигураций декодера видео, определённых комитетом MPEG Reconfigurable Video Coding (RVC);
  • PNaCl (Portable Native Client) - интегрированная в браузер Chrome система, которая позволяет организовать выполнение приложений, написанных на языках C и С++, в специальном изолированном окружении web-браузера, независимо от текущей аппаратной архитектуры;
  • PoCL (Portable Computing Language OpenCL) - реализация стандарта OpenCL, независимая от производителей графических ускорителей и позволяющая использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;
  • Likely - открытый предметно-ориентированный язык для распознавания изображений. Алгоритмы распознавания на лету компилируются (JIT) при помощи инфраструктуры LLVM MCJIT для выполнения на одно- или многоядерных CPU, а также на GPU с использованием OpenCL SPIR или CUDA.
  • LibBeauty - инструментарий для декомпиляции и обратного инжиниринга, построенный с использованием дизассемблера LLVM и LLVM IR Builder. Приняв на входе объектный файл (.o) на выходе генерирует файл в промежуточном представлении LLVM (.bc или .ll);
  • McSema - фреймворк для преобразования машинного кода в биткод LLVM;
  • Swift - основанный на LLVM язык программирования, развиваемый компанией Apple;
  • FTL (Fourth Tier LLVM) - JIT-компилятор для движка WebKit;


  1. Главная ссылка к новости (http://lists.cs.uiuc.edu/piper...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41747-llvm
Ключевые слова: llvm, clang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, iZEN (ok), 01:01, 28/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –18 +/
    > символьного литерала u8

    Неужели сишники признали существование символьных переменных? Ну надо же! Не прошло и сорока лет.

     
     
  • 2.2, Аноним (-), 01:21, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    О чем ты, изя? Char в большинстве реализаций и был по факту u8. Правда в некоторых сильно заковыристых мог и не быть - например некоторые процы принципиально не могут с одним байтом работать, например потому что всегда таскают слово не менее 16 битов, etc. У таких бывал и более широкий char.

    Дефолтные типы в C конечно странноватые, но все эти u8...64 (а в gcc и 128) - уже давно есть. И юзать именно char никто не заставляет. Строка в си - кусок байтов в памяти. И не более того.

     
     
  • 3.9, BratSinot (ok), 10:06, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Вы дурак, батенька. u8 это UTF-8! Он может быть 1, либо 2 байта, в зависимости от символа. Поэтому char не канает.
     
     
  • 4.11, Нанобот (ok), 10:51, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >u8 это UTF-8!

    жесть. си-шники небось специально это придумали, чтобы все путались
    например, в йадре линупс: typedef unsigned char           u8

     
     
  • 5.15, BratSinot (ok), 12:06, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >>u8 это UTF-8!
    > жесть. си-шники небось специально это придумали, чтобы все путались
    > например, в йадре линупс: typedef unsigned char      
    >      u8

    Пусть выкидывают и используют силу C99, в виде stdint.h и всяких int32_t, uint32_t, int8_t и т.д. :)

     
     
  • 6.28, Аноним (-), 14:58, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Пусть выкидывают и используют силу C99, в виде stdint.h и всяких int32_t,
    > uint32_t, int8_t и т.д. :)

    Ты почитай какие гарантии на них даются и потом подумай - хочешь ли ты получить "не менее чем 32 бита" если тебе например надо ровно 32 бита?

     
     
  • 7.31, Аноним (-), 15:28, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    uint32_t даёт _ровно_ 32 бита, по стандарту. Если система не может дать ровно 32 бита, то этот тип должен отсутствовать. То, что вы описываете ("не менее, чем 32 бита") - это int_least32_t.
     
  • 5.27, Аноним (-), 14:56, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > например, в йадре линyпс: typedef unsigned char      
    >      u8

    Вообще-то это "местечковый", но весьма популярный у сишников typedef.

    И на самом деле там все логикино: u8...64 - unsigned int 8 ... 64 бита. s8...64 - аналогично, но signed. Так что массив u8 - массив байтов. А массив u64 - массив 64-битных слов. Достаточно удобно если надо нечто с предсказуемым количеством байтов.

     
  • 4.12, Аноним (-), 11:02, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Разговор трёх идиотов, каждый отстаивает собственный набор заблуждений.

    Как дело обстоит на самом деле:

    Во-первых, utf-8 может быть от одного до 4 байтов (в теории - до 6, но применительно к юникоду - только до 4), а вовсе не "1 либо 2".

    Во-вторых, в C и C++ есть 4 символьных типа и 5 символьных/строковых литералов.

    Типы: char (1 байт, существует с древних времён), wchar_t (широкий символ системно-специфичного размера в неопределённой кодировке, существует с древних времён), char16_t (16-битный широкий символ, UTF-16 если явно не указано обратное, появился недавно), char32_t (32-битный широкий символ, UTF-32 если явно не указано обратное, появился недавно).

    Строковые литералы: "строка" (строка типа char*, в том виде, как представлена в исходниках, без перекодирования), L"строка" (строка типа wchar_t*, перекодируется при компиляции из кодировки исходников в системно-специфичную "широкую" кодировку), u"строка" (строка типа char16_t*, перекодируется при компиляции, появилась недавно), U"строка" (строка типа char32_t*, перекодируется при компиляции, появилась недавно), u8"строка" (строка типа char*, перекодируется из кодировки исходников в UTF-8 и может включать юникодные escape-последовательности, в остальном идентична первому варианту, появилась недавно).

    Символьные литералы: 'символ', L'символ', u'символ', U'символ' - как для строк, но генерирует одиночный символ. u8'символ' - до сих пор не существовал, планируется ввести в будущем стандарте. Это тип char, перекодируется из кодировки исходников в UTF-8; если результат не влезает в char, то это ошибка компиляции (в отличие от соответствующего строкового литерала, где каждый символ имеет полное право занимать несколько char'ов в строке).

     
     
  • 5.14, BratSinot (ok), 12:05, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Насчет размера до 6 не знал, каюсь. Тогда непонятно нафига нужны UTF-16 и UTF-32, если даже в UTF-8 5 и 6 байтов не используются.
     
     
  • 6.17, ананим.orig (?), 12:38, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Utf-16 и -32 — имеют фиксированный размер. "Придуманы" ДО utf8.
    В последнем же переменный размер, например символы анси (английский алфавит как пример) занимает 1 байт, русский влазит в 2, китайский в 3,..
    Например в жабе стандартная строка -16, думали что хватит, но современный юникод не влазит. Из-за чего у айзена и пoпaбoль. :D

    В общем это легаси кодировки (по аналогии с 8-битными кодировками долго не думали, взяли и просто увеличили до 2-х байт, 4-х,.. потом поняли что что-то не так и придумали переменную длину. Старший бит определяет есть ли следующий байт или дальше уже другой символ идёт).

     
     
  • 7.19, ананим.orig (?), 12:57, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    зыж
    А вообще, читайте маны (если есть линух)
    > $ man utf-8

    там даже по-русски, подробно и, что важно, понятно. Например оттуда:
    > Набор  символов  Unicode  3.0 занимает 16-битное кодовое пространство. Наиболее распространённая юникодная кодировка, известная как UCS-2, содержит последовательности 16-битных слов. Закодированные таким образом строки могут состоять из частей 16-битных символов например, '\0' или '/', которые имеют специальное  значение  в  именах файлов и других параметрах функций библиотеки языка Си. Кроме того, большинство утилит UNIX предназначено для обработки ASCII-файлов и не может воспринимать 16-битные слова как символы. По этим причинам UCS-2 является неподходящей кодировкой Unicode для имён файлов, текстовых файлов, переменных окружения  и  т.д.  Набор  ISO  10646 Universal Character Set (UCS), расширенный набор Юникода, занимает более 31-битного кодового пространства, а используемая для него кодировка UCS-4 (последовательность 32-битных слов) имеет те же недостатки, что и описанные выше.
    > Кодировка UTF-8 для представления Unicode и UCS лишена этих недостатков и поэтому в UNIX-подобных операционных системах используется наиболее часто.

    .

     
  • 7.37, Crazy Alex (ok), 17:19, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А вот не надо путать UCS-2 и UTF-16. Первый - фиксированного размера, но не все символы юникода в него влезают. Второй - переменного, как и UTF-8. UTF-32 - фиксированного размера, заведомо вмещает любой уникодный символ.
     
     
  • 8.38, ананим.orig (?), 18:52, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да не путаю я Просто в контексте обсуждения это не имеет смысла, тк utf-16 име... текст свёрнут, показать
     
     
  • 9.50, Crazy Alex (ok), 16:54, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    если на практике это же и максимум - эт UCS-2 UTF-16 - кодировка с переменно... текст свёрнут, показать
     
     
  • 10.54, ананим.orig (?), 18:20, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    171 на практике 187 UCS-2 и UTF-16 8212 это одно и тоже в 99, 9 случае... текст свёрнут, показать
     
  • 8.43, амаима (?), 01:15, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Обе они переменного размера или 2 или 4 байта UCS-2 does not describe a data ... текст свёрнут, показать
     
     
  • 9.51, Crazy Alex (ok), 16:55, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну правильно - в UCS-2 весь современный юникод не влезает Называется пользуйте... текст свёрнут, показать
     
  • 6.18, Аноним (-), 12:44, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    UTF-32 нужна потому, что в ней все символы занимают ровно по 32 бита Т е utf32... большой текст свёрнут, показать
     
     
  • 7.25, Аноним (-), 14:52, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Зато UTF-8 компактнее и совместим с ASCII

    А еще для работы с ним не надо переписывать программы... :)

     
     
  • 8.33, щщзы (?), 15:56, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Всё зависит от того, что вы делаете в программе Иногда - надо Как только встаё... текст свёрнут, показать
     
     
  • 9.44, Аноним (-), 01:32, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Но большнство кода системного, утилит, большинства либ - править не пришлось и... текст свёрнут, показать
     
  • 7.35, Stax (ok), 16:26, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > UTF-16 существует по историческим причинам

    Ну, не надо так зарубать. UTF-16 - это основное и рекомендованное представление Unicode (рекомендованное именно консорциумом Unicode - не когда-то, а прямо сейчас), которое используется практически во всех серьезных проектах. В UNIX-системах популярен UTF-8, но он удобен только тогда, когда в саму строку не нужно вникать, а достаточно принять-передать ее: тут совместимость с ASCII рулит. Но любая обработка (нормализация, поиск и тд) в UTF-8 превращается в извращение.

    По факту, даже в UNIX-системах серьезные проекты используют UTF-16 представление (Java, Python и т.д.). Что касается UTF-32, он, конечно, чуть удобнее, но ЖУТКО неэффективен - даже с учетом самых редких символов для кодирования всех определенных сейчас Unicode 7.0 символов достаточно 21 бита. С практической точки зрения же % символов, которые выходят из BMP совсем мал. Поэтому UTF-32 используют только те, кому лень написать простой if для выявления surrogate point'ов в UTF-16 (если уж совсем вручную обрабатывать, т.к. по факту в высокоуровневых языках поддержка есть внутри) и кому не жаль ради этого потратить в два раза больше памяти. Поэтому официально рекомендуется использовать UTF-16 представление везде, где требуется любая обработка строк, от UTF-32 держаться подальше, кроме представления отдельных символов (а не строк) - кстати, на практике так и делают, у того же питона в памяти UTF-16, но если попросить вывести представление одного символа, оно вернется как UTF-32 - и UTF-8 там, где нужна совместимость с ASCII и особо не требуется обработка.

     
     
  • 8.36, Аноним (-), 17:11, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В Python используется не UTF-16, а wchar_t, который, между прочим, в винде UTF-1... текст свёрнут, показать
     
     
  • 9.41, ананим.orig (?), 19:46, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ну в доках так wchar_t 8212 это целочисленный тип с объёмом, достаточным для... текст свёрнут, показать
     
  • 8.40, ананим.orig (?), 19:15, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А пруфом не поделитесь А то основное достоинство utf-16 8212 совместимость с... текст свёрнут, показать
     
  • 5.21, ананим.orig (?), 14:37, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > u8'символ' - до сих пор не существовал, планируется ввести в будущем стандарте.

    вообще-то уже в стандарте
    C++11 — http://en.cppreference.com/w/cpp/language/string_literal
    > u8 " (unescaped_character|escaped_character)* " (3) (since C++11)

    C11 — http://en.cppreference.com/w/c/language/string_literal
    > u8 " s-char-sequence " (2) (since C11)
    > …
    > References
    >    C11 standard (ISO/IEC 9899:2011):
    >        6.4.5 String literals (p: 70-72)

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

     
     
  • 6.22, Аноним (-), 14:45, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Перечитайте внимательно то, что я написал. _Строковый_ литерал u8"строка" я отнёс к категории "появился недавно", а _символьный_ литерал u8'символ' - будет в следующем стандарте.
     
     
  • 7.30, ананим.orig (?), 15:11, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А, да-да-да. Сори.
     
  • 6.23, ананим.orig (?), 14:45, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    зыж
    а да, пример:
    > $ cat ./222.c
    > #include <stdio.h>
    > int main()
    > {
    >    char s2[] = u8"a猫🍌 Пример — ☯  ☭  ☮";
    >    printf("u8\"%s\" is a char[%zu] holding \n ", s2, sizeof s2 / sizeof *s2);

    }
    > $ gcc -std=c11 -o 222 222.c
    > $ ./222
    > u8"a猫🍌 Пример — ☯  ☭  ☮" is a char[40] holding

    главное -std=c11 не забывать

     
     
  • 7.45, Аноним (-), 01:33, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > главное -std=c11 не забывать

    В свежих компилерах сам врубится. Вон у шланга говорят уже. Ну и у gcc будет, куда ж они денутся при конкуренции...

     
     
  • 8.48, ананим.orig (?), 14:41, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Нафиг не нужно Автоматом врубать это я буду, когда овер 50 ПО это будет требов... текст свёрнут, показать
     
     
  • 9.49, Аноним (-), 15:40, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В новости - о символьном литерале, которого ещё нет в стандартах, а приведённый ... текст свёрнут, показать
     
  • 4.13, suki (?), 11:06, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В иероглифах 3-4 байта на символ.
     
  • 4.20, Аноним (-), 12:59, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Символ в UTF-8 может и 6 байт занимать
     
     
  • 5.32, Аноним (-), 15:53, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    5 и 6 байт могут только теоретически (метод кодирования позволяет), практически в Юникоде не определено столько символов, чтобы потребовалось 5 или 6 байт в utf8.
     
     
  • 6.52, Crazy Alex (ok), 16:59, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А практически - если я увижу в коде, что он закладывается на то, что UTF8-символ не больше 4-х байт - он у меня ревью не пройдёт. Нефиг мины поддержке закладывать.
     
     
  • 7.67, Аноним (-), 22:37, 02/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В таком случае советую обратить внимание на следующее.

    UCS-2 способна представить символы с кодами до 2^16 (не включительно).
    UTF-16 - до 2^20 + 2^16.
    4-byte max UTF-8 - до 2^21.
    полная UTF-8 - до 2^31.
    UTF-32 - до 2^32.
    (всё в порядке возрастания).

    Т.е. если программа использует UTF-16 в качестве внутреннего представления (как некоторые тут рекомендовали) и перекодирует в него пользовательский ввод из UTF-8, то она вынуждена отвергать 5- и 6-байтные символы UTF-8 как непредставимые в UTF-16, а значит, по сформулированному вами критерию, не должна пройти у вас ревью.

     
  • 6.59, Аноним (-), 22:16, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > 5 и 6 байт могут только теоретически (метод кодирования позволяет), практически в
    > Юникоде не определено столько символов, чтобы потребовалось 5 или 6 байт
    > в utf8.

    Что ты, вихрь. Ты кантонский диалект видал?

     
     
  • 7.63, КО (?), 12:50, 02/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >Что ты, вихрь. Ты кантонский диалект видал?

    Укладывался он спокойно.
    Вот, когда начали цветные смайлики кодировать...

     
  • 4.24, Аноним (-), 14:51, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы дурак, батенька. u8 это UTF-8!

    У сишников u8 сроду означало unsigned integer, 8 битов.

     
  • 4.26, Аноним (-), 14:53, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Он может быть 1, либо 2 байта,

    А японцы с их закорючками не в курсе - там и все 4 бывает...

     
  • 2.5, Аноним (-), 02:17, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Господи, насколько же ты безграмотен.
     
  • 2.7, Аноним (-), 07:42, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    char и wchar_t?
     
     
  • 3.10, BratSinot (ok), 10:07, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > char и wchar_t?

    char всегда 1 байт, wchar_t всегда 2, а u8 это литерал: u8"СтрокаASD".

     
     
  • 4.16, Аноним (-), 12:07, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > wchar_t всегда 2

    Нет, не всегда.

     
  • 4.29, Аноним (-), 15:00, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > char всегда 1 байт

    Это не так. Стандарт определяет что "не менее 1 байта". Поэтому бывали чудесатые компилеры для DSP где char 16 битов. Потому что проц не умеет 8 битов адресовать и видит мир только 16-битными словами, хоть там что. Формально спеки не нарушает :).

     
     
  • 5.66, Анонимко (?), 15:07, 02/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    char всегда один байт. Другое дело один байт не всегда 8 бит.
     
  • 4.34, щщзы (?), 16:11, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > char всегда 1 байт, wchar_t всегда 2

    по первой части - в зависимости от того, как определите байт (как 8 бит или как мин. адресуемая единица памяти) может быть верно или неверно. Верно, что sizeof(char) == 1.

    по второй части - sizeof(wchar_t) == 4 на компьютере с которого пишу (x86_64 GNU/Linux).

     

  • 1.3, Аноним (-), 01:41, 28/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    круто
    Цианогенмод когда на это попробует перейти?
     
     
  • 2.8, Andrey Mitrofanov (?), 09:12, 28/02/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > круто
    > Цианогенмод когда на это попробует перейти?

    Как тольто узнает что 1/ это "круто", 2/ уже надо переходить, так сразу, задрав штаны, и побежит. Отбей ему молнию!

     

  • 1.39, anonymous (??), 19:07, 28/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Применяемый по умолчанию режим языка Си изменён с C99 с расширениями GNU на C11 с расширениями GNU;
    > с расширениями

    А вот за такое бить нужно смертным боем.

     
     
  • 2.46, Аноним (-), 01:37, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот за такое бить нужно смертным боем.

    Так живых компилеров С по сути есть два. Шланг и гцц. Остальные где-то в ... - так что можно использовать сие и не беспокоиться. Извращенцы с вьюжлстудией и прочим крапом могут идти в пень: MS давно забил на си и даже во многом на плюсы, так что равняться на подобных ни к чему. У эппла свой objC и они как обычно сами по себе.

     
     
  • 3.47, бот от мс (?), 13:53, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно забила? пилят вон вовсю С++11/14 в новой студии:
    http://www.visualstudio.com/en-us/news/vs2015-preview-vs#C++
     
     
  • 4.53, Crazy Alex (ok), 17:01, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    C и С++ не различаешь? Бывает.
    Они не сподобились даже C99 под WinPhone сделать до сих пор.
     
  • 2.55, Аноним (-), 18:48, 01/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, за что именно? C11 или расширения GNU? Во-вторых, аргументируй. Про GNU ещё можно поспорить, но современный стандарт _обязан_ поддерживаться по умолчанию.
     

  • 1.42, Аноним (-), 23:53, 28/02/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Виртуальная машина - это виртуальная машина, - серьезно ответил программист, вставая,
    - чуть быстрее, чуть медленнее - все едино, пропорции условны, а границы размыты. Я не святой, писал программы не только на ассемблере. Но
    если мне приходится выбирать между java и c# - я предпочитаю не выбирать вовсе.
     
  • 1.62, Петруччо (?), 12:37, 02/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Значительно улучшена поддержка платформы Windows. Достигнут уровня самопересборки (self host) в окружении msvc на x86 и x64 системах Windows. Кроме исключений, поддержка Microsoft C++ ABI более-менее полностью реализована;

    Наконец-то будут нормально собранные программы, и можно будет опять переходить на Windows!

     
     
  • 2.64, Andrey Mitrofanov (?), 13:08, 02/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Наконец-то будут нормально собранные программы, и можно будет опять переходить на Windows!

    Не. Я бы посмотрел, как Эппле сдюжит тащить тот майкросовтовский "багаж". Ну, скажем 3-4 мажорнызх релиза этой их винды. Нельзя _так торопиться-то.

     
  • 2.65, Crazy Alex (ok), 14:54, 02/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Иди, болезный. Иди. Лесом, затем полем.
     

  • 1.68, iZEN (ok), 19:24, 02/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну вот и всё. Светлая память. R.I.P.

    - Nuke llvm36/clang36 - Obsolete and unmaintained upstream

    http://www.freshports.org/devel/llvm36/
    http://www.freshports.org/lang/clang36/

     

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



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

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