форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Новая версия набора компиляторов 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"	+/–
Сообщение от Петруччо 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 | Индекс форумов | Темы | Пред. тема | След. тема