The OpenNET Project / Index page

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

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"Новая версия набора компиляторов LLVM 3.6"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от opennews (ok) on 28-Фев-15, 01:01 
Представлен (http://lists.cs.uiuc.edu/pipermail/llvm-announce/2015-Februa...) релиз проекта LLVM 3.6 (http://llvm.org) (Low Level Virtual Machine) - GCC совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод (http://llvm.org/docs/BitCodeFormat.html) RISC подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.


Улучшения (http://llvm.org/releases/3.6.0/tools/clang/docs/ReleaseNotes...) в 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;


Основные новшества (http://llvm.org/releases/3.6.0/docs/ReleaseNotes.html) LLVM 3.6:


-  В состав включен набор биндингов для обеспечения поддержки развиваемого компанией Google языка программирования Go, который позиционируется как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Принятый код основан на наработках проекта LLVM Go (https://github.com/go-llvm/llvm), разработчики которого согласились перелицензировать код под лицензией LLVM и предложили свою работу для включения в основной состав LLVM. Включение биндингов в состав LLVM является необходимым условием дальнейшей интеграции в LLVM фронтэнда с компилятором для языка Go (llgo), который построен с использованием данных биндингов.

-  Проект LLVMLinux (http://llvm.linuxfoundation.org/index.php/Main_Page) достиг уровня, при котором возможна пересборка ядра 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;
-  Добавлен новый экспериментальный механизм для описания точек сохранения (http://llvm.org/docs/Statepoints.html) (safepoint) в сборщике мусора;

-  Отмечен прогресс в реализации проекта Portable Computing Language OpenCL (PoCL (http://pocl.sourceforge.net/)), в рамках которого ведётся разработка полностью открытой реализации стандарта OpenCL, независимой от производителей графических ускорителей. PoCL позволит (http://www.opennet.me/opennews/art.shtml?num=32092) разработчикам не задумываться об особенностях той или иной реализации стандарта и использовать предоставляемые компилятором оптимизации вместо применения специфических для каждой платформы техник ручной оптимизации. PoCL реализован по модульному принципу, позволяющему использовать различные бэкенды для выполнения OpenCL-ядер на разных типах графических и центральных процессоров;


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


-  KLEE (http://klee.llvm.org/) - символьный анализатор и генератор тестовых наборов;

-  Runtime-библиотека compiler-rt (http://compiler-rt.llvm.org/);

-  llvm-mc (http://llvm.org/releases/2.6/docs/ReleaseNotes.html#mc) - автогенератор ассемблера, дизассемблера и других связанных с машинным кодом компонентов на основе описаний параметров LLVM-совместимых платформ.

-  Реализация функционального языка программирования Pure (http://pure-lang.googlecode.com/);

-   LDC (http://www.dsource.org/projects/ldc) - компилятор для языка D;

-  Roadsend PHP (http://www.roadsend.com/) - оптимизатор, статический и JIT компилятор для языка PHP;

-  Виртуальные машины для Ruby: Rubinius (http://rubini.us/) и MacRuby (http://www.macruby.org/);

-  LLVM-Lua (http://code.google.com/p/llvm-lua/)

-  FlashCCompiler (http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler.pdf) - средство для компиляции кода на языке Си в вид, пригодный для выполнения в виртуальной машине Adobe Flash;

-  LLDB (http://lldb.llvm.org/) - новая (http://www.opennet.me/opennews/art.shtml?num=26907)  модульная инфраструктура отладки, использующая такие подсистемы LLVM как API для дизассемблирования, Clang AST (Abstract Syntax Tree), парсер выражений, генератор кода и JIT-компилятор. LLDB поддерживает отладку многопоточных программ на языках C, Objective-C и C++; отличается возможностью подключения плагинов и скриптов на языке Python; показывает крайне высокое быстродействие при отладке программ большого размера;

-  emscripten (https://github.com/kripken/emscripten/wiki) - компилятор биткода LLVM в JavaScript, позволяющий преобразовать для запуска в браузере приложения, изначально написанные на языке Си. Например, удалось запустить Python, Lua, Quake, Freetype;

-  sparse-llvm (https://github.com/penberg/sparse-llvm) - бэкенд, нацеленный (http://www.opennet.me/opennews/art.shtml?num=31636) на создание Си-компилятора, способного собирать ядро Linux.

-  Portable OpenCL (http://www.opennet.me/opennews/art.shtml?num=32092) -  открытая и независимая реализация стандарта OpenCL;

-  CUDA Compiler (http://www.opennet.me/opennews/art.shtml?num=33800) - позволяет сгенерировать GPU-инструкции из кода, написанного на языках Си, Си++ и Fortran;

-  Julia (http://www.opennet.me/opennews/art.shtml?num=33315) - открытый динамический язык программирования, использующий наработки проекта LLVM.

-  Jade (https://github.com/orcc/jade) (Just-in-time Adaptive Decoder Engine) - универсальный движок для декодирования видео, использующий LLVM для JIT-компиляции адаптивных конфигураций декодера видео, определённых комитетом MPEG...

URL: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2015-Februa...
Новость: http://www.opennet.me/opennews/art.shtml?num=41747

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Новая версия набора компиляторов LLVM 3.6"  –18 +/
Сообщение от iZEN (ok) on 28-Фев-15, 01:01 
> символьного литерала u8

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Новая версия набора компиляторов LLVM 3.6"  +2 +/
Сообщение от Аноним (??) on 28-Фев-15, 01:21 
О чем ты, изя? Char в большинстве реализаций и был по факту u8. Правда в некоторых сильно заковыристых мог и не быть - например некоторые процы принципиально не могут с одним байтом работать, например потому что всегда таскают слово не менее 16 битов, etc. У таких бывал и более широкий char.

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

9. "Новая версия набора компиляторов LLVM 3.6"  –6 +/
Сообщение от BratSinot (ok) on 28-Фев-15, 10:06 
Вы дурак, батенька. u8 это UTF-8! Он может быть 1, либо 2 байта, в зависимости от символа. Поэтому char не канает.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

11. "Новая версия набора компиляторов LLVM 3.6"  –3 +/
Сообщение от Нанобот (ok) on 28-Фев-15, 10:51 
>u8 это UTF-8!

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

15. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от BratSinot (ok) on 28-Фев-15, 12:06 
>>u8 это UTF-8!
> жесть. си-шники небось специально это придумали, чтобы все путались
> например, в йадре линупс: typedef unsigned char      
>      u8

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

28. "Новая версия набора компиляторов LLVM 3.6"  –1 +/
Сообщение от Аноним (??) on 28-Фев-15, 14:58 
> Пусть выкидывают и используют силу C99, в виде stdint.h и всяких int32_t,
> uint32_t, int8_t и т.д. :)

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

31. "Новая версия набора компиляторов LLVM 3.6"  +1 +/
Сообщение от Аноним (??) on 28-Фев-15, 15:28 
uint32_t даёт _ровно_ 32 бита, по стандарту. Если система не может дать ровно 32 бита, то этот тип должен отсутствовать. То, что вы описываете ("не менее, чем 32 бита") - это int_least32_t.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

27. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 28-Фев-15, 14:56 
> например, в йадре линyпс: typedef unsigned char      
>      u8

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

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

12. "Новая версия набора компиляторов LLVM 3.6"  +12 +/
Сообщение от Аноним (??) on 28-Фев-15, 11:02 
Разговор трёх идиотов, каждый отстаивает собственный набор заблуждений.

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

Во-первых, 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'ов в строке).

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

14. "Новая версия набора компиляторов LLVM 3.6"  –1 +/
Сообщение от BratSinot (ok) on 28-Фев-15, 12:05 
Насчет размера до 6 не знал, каюсь. Тогда непонятно нафига нужны UTF-16 и UTF-32, если даже в UTF-8 5 и 6 байтов не используются.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "Новая версия набора компиляторов LLVM 3.6"  +4 +/
Сообщение от ананим.orig on 28-Фев-15, 12:38 
Utf-16 и -32 — имеют фиксированный размер. "Придуманы" ДО utf8.
В последнем же переменный размер, например символы анси (английский алфавит как пример) занимает 1 байт, русский влазит в 2, китайский в 3,..
Например в жабе стандартная строка -16, думали что хватит, но современный юникод не влазит. Из-за чего у айзена и пoпaбoль. :D

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

19. "Новая версия набора компиляторов LLVM 3.6"  +1 +/
Сообщение от ананим.orig on 28-Фев-15, 12:57 
зыж
А вообще, читайте маны (если есть линух)
> $ 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-подобных операционных системах используется наиболее часто.

.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

37. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Crazy Alex (ok) on 28-Фев-15, 17:19 
А вот не надо путать UCS-2 и UTF-16. Первый - фиксированного размера, но не все символы юникода в него влезают. Второй - переменного, как и UTF-8. UTF-32 - фиксированного размера, заведомо вмещает любой уникодный символ.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

38. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от ананим.orig on 28-Фев-15, 18:52 
Да не путаю я. Просто в контексте обсуждения это не имеет смысла, тк. utf-16 имеет на практике все теже минусы — не совместим с анси, следавательно и со старым ПО, минимум 2-х байтовый (в большинстве случаев на практике это же и максимум), ..., плюс единственный минус utf-8 — считать позицию символа также не удобно.
Пруф — https://ru.m.wikipedia.org/wiki/UTF-16
> UTF-16 (англ. Unicode Transformation Format) в информатике — один из способов кодирования символов из Юникода в виде последовательности 16-битных слов. Данная кодировка позволяет записывать символы Юникода в диапазонах U+0000..U+D7FF и U+E000..U+10FFFF (общим количеством 1 112 064). При этом каждый символ записывается одним или двумя словами (суррогатная пара).

... в виде последовательности 16-битных слов ... каждый символ записывается одним или двумя словами ...
В общем ни то, ни сё. Utf-8 явно более прогрессивен по конструкции.
Единственное "достоинство" — в него вантуз вляпался. :D
А посему до сих пор тянет в обязательном порядке за собой и 8-битовые кодировки (аля cp1251).

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

50. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Crazy Alex (ok) on 01-Мрт-15, 16:54 
если " на практике это же и максимум" - эт UCS-2. UTF-16 - кодировка с переменной длиной.
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

54. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от ананим.orig on 01-Мрт-15, 18:20 
«на практике» UCS-2 и UTF-16 — это одно и тоже (в 99,(9)% случаев).
Последний собственно для этого и был придуман. Для рамок коментариев этого достаточно.
В частности хоть в вантузе (до winxp включительно) utf-16, набор символов ограничен ucs-2.
Это первое.

Но если лично вам нужны пояснения, пожалуйста:
Второе (для програмистов… тех кто понимает) — в вантузе нет возможности поддерживать utf-16 больше чем в 2-х байтовом варианте.
TCHAR (основа работы со строками в winapi) в вантузе определён просто:
> #ifdef _UNICODE
> typedef wchar_t TCHAR;
> #else
> typedef char TCHAR;
> #endif

в свою очередь wchar_t в вантузе имеет размер 2 байта. Поэтому в вантузе те, кому нужны сиволы более ucs-2 вынуждены использовать utf-32. Пример:
> The Python language environment officially only uses UCS-2 internally since version 2.0, but the UTF-8 decoder to "Unicode" produces correct UTF-16. Since Python 2.2, "wide" builds of Unicode are supported which use UTF-32 instead;[15] these are primarily used on Linux. Python 3.3 no longer ever uses UTF-16, instead strings are stored in one of ASCII/Latin-1, UCS-2, or UTF-32, depending on which code points are in the string, with a UTF-8 version also included so that repeated conversions to UTF-8 are fast.[16]

http://en.wikipedia.org/wiki/UTF-16#Usage
Или тут http://blogerator.ru/page/windows-total-commander-iview :
> Есть и приятные моменты. Например, полная поддержка Unicode в TC (total-commander) была написана мной вручную, тогда как в Lazarus все контролы изначально поддерживают Unicode и базируются на UTF-8.

Так что «на практике» поддержка utf-16 вроде есть, но он от ucs-2 (который раньше вообще назывался просто — unicode) ничем не отличается.

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

43. "Новая версия набора компиляторов LLVM 3.6"  +1 +/
Сообщение от амаима on 01-Мрт-15, 01:15 
> А вот не надо путать UCS-2 и UTF-16. Первый - фиксированного размера, но не все символы юникода в него влезают. Второй - переменного

Обе они переменного размера (или 2 или 4 байта) (UCS-2 does not describe a data format distinct from UTF-16), однако уцс-2 не интерпретирует 4 байтовые символы если они там попадаются.

http://www.unicode.org/faq/utf_bom.html#utf16-11

Q: What is the difference between UCS-2 and UTF-16?

UCS-2 does not describe a data format distinct from UTF-16, because both use exactly the same 16-bit code unit representations. However, UCS-2 does not interpret surrogate code points, and thus cannot be used to conformantly represent supplementary characters.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

51. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Crazy Alex (ok) on 01-Мрт-15, 16:55 
Ну правильно - в UCS-2 весь современный юникод не влезает. Называется "пользуйтесь если ищете себе проблемы".
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

18. "Новая версия набора компиляторов LLVM 3.6"  +1 +/
Сообщение от Аноним (??) on 28-Фев-15, 12:44 
UTF-32 нужна потому, что в ней все символы занимают ровно по 32 бита. Т.е. utf32_str[N] вернёт ровно N+1й символ. Удобнее работать. А в UTF-8, чтобы определить где начинается N-й символ, нужно прочитать все символы до него. Зато UTF-8 компактнее и совместим с ASCII.

UTF-16 существует по историческим причинам. Раньше юникод был 16-битным, и многие операционки и кроссплатформенные языки (та же Java) оказались жёстко завязаны на то, что широкий символ занимает 16 бит. Когда этого размера стало недостаточно, для них пришлось вводить специальную кодировку, UTF-16, в которой каждый элемент занимает 16 бит, но некоторые символы занимают 1 элемент, а некоторые - 2. Имеющихся у UTF-32 преимуществ перед UTF-8 эта кодировка не имеет, т.к. в ней тоже приходится читать всю строку, чтобы найти N-й символ (зато имеет недостатки обеих кодировок), но её пришлось вводить, чтобы не ломать обратную совместимость переходом на UTF-32.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

25. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 28-Фев-15, 14:52 
> Зато UTF-8 компактнее и совместим с ASCII

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

33. "Новая версия набора компиляторов LLVM 3.6"  +2 +/
Сообщение от щщзы on 28-Фев-15, 15:56 
Всё зависит от того, что вы делаете в программе.
Иногда - надо. Как только встаёт вопрос выделения букв в строке или форматирования выводимого текста по ширине, так сразу и надо.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

44. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 01-Мрт-15, 01:32 
> Иногда - надо. Как только встаёт вопрос выделения букв в строке или
> форматирования выводимого текста по ширине, так сразу и надо.

Но большнство кода (системного, утилит, большинства либ) - править не пришлось или совсем, или минимально. По поводу чего UTF-8 и стал столь активно использоваться, задвинух всех остальных куда подальше. Выделять буквы надо, но - только сильно некторому софту. Коего зело меньше чем всего остального.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

35. "Новая версия набора компиляторов LLVM 3.6"  –1 +/
Сообщение от Stax (ok) on 28-Фев-15, 16:26 
> 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 и особо не требуется обработка.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

36. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 28-Фев-15, 17:11 
> кстати, на практике так и делают, у того же питона в памяти UTF-16, но если попросить вывести представление одного символа,  оно вернется как UTF-32 - и UTF-8 там, где нужна совместимость с ASCII и особо не требуется обработка.

В Python используется не UTF-16, а wchar_t, который, между прочим, в винде UTF-16, а в линуксе и маке - UTF-32.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

41. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от ананим.orig on 28-Фев-15, 19:46 
> В Python используется не UTF-16, а wchar_t, который, между прочим, в винде UTF-16, а в линуксе и маке - UTF-32.

ну в доках так: wchar_t — это целочисленный тип с объёмом, достаточным для представления самого большого расширенного набора символов в системе.
С учётом http://en.wikipedia.org/wiki/UTF-16#Usage :
> UTF-16 is used for text in the OS API in Microsoft Windows 2000/XP/2003/Vista/7/8/CE.[10] Older Windows NT systems (prior to Windows 2000) only support UCS-2.[11] In Windows XP, no code point above U+FFFF is included in any font delivered with Windows for European languages.

То вывод такой - wchar_t в винде не utf-16, а UCS-2.
Собственно из-за этой небольшой проблемы в с++11 и ввели char16_t и char32_t, чтобы все символы и в вантузе (последних версий, те что позже хп) влезли, и на других системах совместимость особо не терялась.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

40. "Новая версия набора компиляторов LLVM 3.6"  +1 +/
Сообщение от ананим.orig on 28-Фев-15, 19:15 
> Ну, не надо так зарубать. UTF-16 - это основное и рекомендованное представление Unicode

А пруфом не поделитесь?
А то основное достоинство utf-16 — совместимость с (цитата) "UTF-16 developed from an earlier fixed-width 16-bit encoding known as UCS-2 (for 2-byte Universal Character Set) once it became clear that a fixed-width 2-byte encoding could not encode enough characters to be truly universal".
Utf-16 имеет все недостатки и кодировок переменной длины, и фиксированной. И нужен только для совместимости со старыми системами, которые "вляпались" в "старый" юникод.
Вон для того же xml, xhtml,.. стандарт — utf-8.
Ни о каких предпочтениях в стандартах ни гу-гу. Каким удобней, тем и пользуйтесь. А вот в вантузе — да. Он utf-8 не умеет (не умел вернее. в сети есть интервью с создателем тоталкоммандера, который был вынужден под вантуз написать свою реализацию юникода. Не от хорошей жизни).
Пруф:
> UTF-16 is used for text in the OS API in Microsoft Windows 2000/XP/2003/Vista/7/8/CE.[10] Older Windows NT systems (prior to Windows 2000) only support UCS-2.[11] In Windows XP, no code point above U+FFFF is included in any font delivered with Windows for European languages.[12][13] Files and network data tend to be a mix of UTF-16, UTF-8, and legacy byte encodings.

http://en.m.wikipedia.org/wiki/UTF-16#Usage

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

21. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от ананим.orig on 28-Фев-15, 14:37 
> 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 уже поддерживает по крайней мере.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

22. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 28-Фев-15, 14:45 
Перечитайте внимательно то, что я написал. _Строковый_ литерал u8"строка" я отнёс к категории "появился недавно", а _символьный_ литерал u8'символ' - будет в следующем стандарте.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

30. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от ананим.orig on 28-Фев-15, 15:11 
А, да-да-да. Сори.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

23. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от ананим.orig on 28-Фев-15, 14:45 
зыж
а да, пример:
> $ 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 не забывать

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

45. "Новая версия набора компиляторов LLVM 3.6"  –2 +/
Сообщение от Аноним (??) on 01-Мрт-15, 01:33 
> главное -std=c11 не забывать

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

48. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от ананим.orig on 01-Мрт-15, 14:41 
Нафиг не нужно.
Автоматом врубать это я буду, когда овер 50% ПО это будет требовать.
И случится это ещё не скоро.
Gcc этот пример компилит с версии 4.6 (может и раньше, но я не пробовал), шланг, судя по новости, только сейчас.
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

49. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 01-Мрт-15, 15:40 
В новости - о символьном литерале, которого ещё нет в стандартах, а приведённый пример - о строковом.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

13. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от suki on 28-Фев-15, 11:06 
В иероглифах 3-4 байта на символ.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

20. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 28-Фев-15, 12:59 
Символ в UTF-8 может и 6 байт занимать
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

32. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 28-Фев-15, 15:53 
5 и 6 байт могут только теоретически (метод кодирования позволяет), практически в Юникоде не определено столько символов, чтобы потребовалось 5 или 6 байт в utf8.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

52. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Crazy Alex (ok) on 01-Мрт-15, 16:59 
А практически - если я увижу в коде, что он закладывается на то, что UTF8-символ не больше 4-х байт - он у меня ревью не пройдёт. Нефиг мины поддержке закладывать.
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

67. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 02-Мрт-15, 22:37 
В таком случае советую обратить внимание на следующее.

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, а значит, по сформулированному вами критерию, не должна пройти у вас ревью.

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

59. "Новая версия набора компиляторов LLVM 3.6"  –1 +/
Сообщение от Аноним (??) on 01-Мрт-15, 22:16 
> 5 и 6 байт могут только теоретически (метод кодирования позволяет), практически в
> Юникоде не определено столько символов, чтобы потребовалось 5 или 6 байт
> в utf8.

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

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

63. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от КО on 02-Мрт-15, 12:50 
>Что ты, вихрь. Ты кантонский диалект видал?

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

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

24. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 28-Фев-15, 14:51 
> Вы дурак, батенька. u8 это UTF-8!

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

26. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 28-Фев-15, 14:53 
> Он может быть 1, либо 2 байта,

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

5. "Новая версия набора компиляторов LLVM 3.6"  +1 +/
Сообщение от Аноним (??) on 28-Фев-15, 02:17 
Господи, насколько же ты безграмотен.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

7. "Новая версия набора компиляторов LLVM 3.6"  –1 +/
Сообщение от Аноним (??) on 28-Фев-15, 07:42 
char и wchar_t?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

10. "Новая версия набора компиляторов LLVM 3.6"  –2 +/
Сообщение от BratSinot (ok) on 28-Фев-15, 10:07 
> char и wchar_t?

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

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

16. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 28-Фев-15, 12:07 
> wchar_t всегда 2

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

29. "Новая версия набора компиляторов LLVM 3.6"  +1 +/
Сообщение от Аноним (??) on 28-Фев-15, 15:00 
> char всегда 1 байт

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

66. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Анонимко on 02-Мрт-15, 15:07 
char всегда один байт. Другое дело один байт не всегда 8 бит.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

34. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от щщзы on 28-Фев-15, 16:11 
> char всегда 1 байт, wchar_t всегда 2

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

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

3. "Новая версия набора компиляторов LLVM 3.6"  –2 +/
Сообщение от Аноним (??) on 28-Фев-15, 01:41 
круто
Цианогенмод когда на это попробует перейти?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Andrey Mitrofanov on 28-Фев-15, 09:12 
> круто
> Цианогенмод когда на это попробует перейти?

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

39. "Новая версия набора компиляторов LLVM 3.6"  –2 +/
Сообщение от anonymous (??) on 28-Фев-15, 19:07 
> Применяемый по умолчанию режим языка Си изменён с C99 с расширениями GNU на C11 с расширениями GNU;
> с расширениями

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

46. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 01-Мрт-15, 01:37 
> А вот за такое бить нужно смертным боем.

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

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

47. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от бот от мс on 01-Мрт-15, 13:53 
Да ладно забила? пилят вон вовсю С++11/14 в новой студии:
http://www.visualstudio.com/en-us/news/vs2015-preview-vs#C++
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

53. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Crazy Alex (ok) on 01-Мрт-15, 17:01 
C и С++ не различаешь? Бывает.
Они не сподобились даже C99 под WinPhone сделать до сих пор.
Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

55. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Аноним (??) on 01-Мрт-15, 18:48 
Во-первых, за что именно? C11 или расширения GNU? Во-вторых, аргументируй. Про GNU ещё можно поспорить, но современный стандарт _обязан_ поддерживаться по умолчанию.
Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

42. "Новая версия набора компиляторов LLVM 3.6"  +4 +/
Сообщение от Аноним (??) on 28-Фев-15, 23:53 
Виртуальная машина - это виртуальная машина, - серьезно ответил программист, вставая,
- чуть быстрее, чуть медленнее - все едино, пропорции условны, а границы размыты. Я не святой, писал программы не только на ассемблере. Но
если мне приходится выбирать между java и c# - я предпочитаю не выбирать вовсе.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

62. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Петруччо email on 02-Мрт-15, 12:37 
Значительно улучшена поддержка платформы Windows. Достигнут уровня самопересборки (self host) в окружении msvc на x86 и x64 системах Windows. Кроме исключений, поддержка Microsoft C++ ABI более-менее полностью реализована;

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

64. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Andrey Mitrofanov on 02-Мрт-15, 13:08 
> Наконец-то будут нормально собранные программы, и можно будет опять переходить на Windows!

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

Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

65. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от Crazy Alex (ok) on 02-Мрт-15, 14:54 
Иди, болезный. Иди. Лесом, затем полем.
Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

68. "Новая версия набора компиляторов LLVM 3.6"  +/
Сообщение от iZEN (ok) on 02-Май-17, 19:24 
Ну вот и всё. Светлая память. R.I.P.

- Nuke llvm36/clang36 - Obsolete and unmaintained upstream

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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