The OpenNET Project / Index page

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

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


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

Оглавление

Новая версия набора компиляторов LLVM 3.6, opennews (ok), 28-Фев-15, (0) [смотреть все]

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

27. "Новая версия набора компиляторов LLVM 3.6"  +/–
Сообщение от Аноним (-), 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 +/–
Сообщение от Аноним (-), 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), 28-Фев-15, 12:05 
Насчет размера до 6 не знал, каюсь. Тогда непонятно нафига нужны UTF-16 и UTF-32, если даже в UTF-8 5 и 6 байтов не используются.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

19. "Новая версия набора компиляторов LLVM 3.6"  +1 +/–
Сообщение от ананим.orig (?), 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-подобных операционных системах используется наиболее часто.

.

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

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

38. "Новая версия набора компиляторов LLVM 3.6"  +/–
Сообщение от ананим.orig (?), 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).

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

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

54. "Новая версия набора компиляторов LLVM 3.6"  +/–
Сообщение от ананим.orig (?), 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) ничем не отличается.

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

43. "Новая версия набора компиляторов LLVM 3.6"  +1 +/–
Сообщение от амаима (?), 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), 01-Мрт-15, 16:55 
Ну правильно - в UCS-2 весь современный юникод не влезает. Называется "пользуйтесь если ищете себе проблемы".
Ответить | Правка | Наверх | Cообщить модератору

18. "Новая версия набора компиляторов LLVM 3.6"  +1 +/–
Сообщение от Аноним (-), 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"  +/–
Сообщение от Аноним (-), 28-Фев-15, 14:52 
> Зато UTF-8 компактнее и совместим с ASCII

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

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

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

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

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

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

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

35. "Новая версия набора компиляторов LLVM 3.6"  –1 +/–
Сообщение от Stax (ok), 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"  +/–
Сообщение от Аноним (-), 28-Фев-15, 17:11 
> кстати, на практике так и делают, у того же питона в памяти UTF-16, но если попросить вывести представление одного символа,  оно вернется как UTF-32 - и UTF-8 там, где нужна совместимость с ASCII и особо не требуется обработка.

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

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

41. "Новая версия набора компиляторов LLVM 3.6"  +/–
Сообщение от ананим.orig (?), 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, чтобы все символы и в вантузе (последних версий, те что позже хп) влезли, и на других системах совместимость особо не терялась.

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

40. "Новая версия набора компиляторов LLVM 3.6"  +1 +/–
Сообщение от ананим.orig (?), 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 (?), 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"  +/–
Сообщение от Аноним (-), 28-Фев-15, 14:45 
Перечитайте внимательно то, что я написал. _Строковый_ литерал u8"строка" я отнёс к категории "появился недавно", а _символьный_ литерал u8'символ' - будет в следующем стандарте.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

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

67. "Новая версия набора компиляторов LLVM 3.6"  +/–
Сообщение от Аноним (-), 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, а значит, по сформулированному вами критерию, не должна пройти у вас ревью.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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