1.1, iZEN (ok), 01:01, 28/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –18 +/– |
> символьного литерала u8
Неужели сишники признали существование символьных переменных? Ну надо же! Не прошло и сорока лет.
| |
|
2.2, Аноним (-), 01:21, 28/02/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
О чем ты, изя? Char в большинстве реализаций и был по факту u8. Правда в некоторых сильно заковыристых мог и не быть - например некоторые процы принципиально не могут с одним байтом работать, например потому что всегда таскают слово не менее 16 битов, etc. У таких бывал и более широкий char.
Дефолтные типы в C конечно странноватые, но все эти u8...64 (а в gcc и 128) - уже давно есть. И юзать именно char никто не заставляет. Строка в си - кусок байтов в памяти. И не более того.
| |
|
3.9, BratSinot (ok), 10:06, 28/02/2015 [^] [^^] [^^^] [ответить]
| –6 +/– |
Вы дурак, батенька. u8 это UTF-8! Он может быть 1, либо 2 байта, в зависимости от символа. Поэтому char не канает.
| |
|
4.11, Нанобот (ok), 10:51, 28/02/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
>u8 это UTF-8!
жесть. си-шники небось специально это придумали, чтобы все путались
например, в йадре линупс: typedef unsigned char u8
| |
|
5.15, BratSinot (ok), 12:06, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
>>u8 это UTF-8!
> жесть. си-шники небось специально это придумали, чтобы все путались
> например, в йадре линупс: typedef unsigned char
> u8
Пусть выкидывают и используют силу C99, в виде stdint.h и всяких int32_t, uint32_t, int8_t и т.д. :)
| |
|
6.28, Аноним (-), 14:58, 28/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Пусть выкидывают и используют силу C99, в виде stdint.h и всяких int32_t,
> uint32_t, int8_t и т.д. :)
Ты почитай какие гарантии на них даются и потом подумай - хочешь ли ты получить "не менее чем 32 бита" если тебе например надо ровно 32 бита?
| |
|
7.31, Аноним (-), 15:28, 28/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
uint32_t даёт _ровно_ 32 бита, по стандарту. Если система не может дать ровно 32 бита, то этот тип должен отсутствовать. То, что вы описываете ("не менее, чем 32 бита") - это int_least32_t.
| |
|
|
5.27, Аноним (-), 14:56, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> например, в йадре линyпс: typedef unsigned char
> u8
Вообще-то это "местечковый", но весьма популярный у сишников typedef.
И на самом деле там все логикино: u8...64 - unsigned int 8 ... 64 бита. s8...64 - аналогично, но signed. Так что массив u8 - массив байтов. А массив u64 - массив 64-битных слов. Достаточно удобно если надо нечто с предсказуемым количеством байтов.
| |
|
4.12, Аноним (-), 11:02, 28/02/2015 [^] [^^] [^^^] [ответить]
| +12 +/– |
Разговор трёх идиотов, каждый отстаивает собственный набор заблуждений.
Как дело обстоит на самом деле:
Во-первых, utf-8 может быть от одного до 4 байтов (в теории - до 6, но применительно к юникоду - только до 4), а вовсе не "1 либо 2".
Во-вторых, в C и C++ есть 4 символьных типа и 5 символьных/строковых литералов.
Типы: char (1 байт, существует с древних времён), wchar_t (широкий символ системно-специфичного размера в неопределённой кодировке, существует с древних времён), char16_t (16-битный широкий символ, UTF-16 если явно не указано обратное, появился недавно), char32_t (32-битный широкий символ, UTF-32 если явно не указано обратное, появился недавно).
Строковые литералы: "строка" (строка типа char*, в том виде, как представлена в исходниках, без перекодирования), L"строка" (строка типа wchar_t*, перекодируется при компиляции из кодировки исходников в системно-специфичную "широкую" кодировку), u"строка" (строка типа char16_t*, перекодируется при компиляции, появилась недавно), U"строка" (строка типа char32_t*, перекодируется при компиляции, появилась недавно), u8"строка" (строка типа char*, перекодируется из кодировки исходников в UTF-8 и может включать юникодные escape-последовательности, в остальном идентична первому варианту, появилась недавно).
Символьные литералы: 'символ', L'символ', u'символ', U'символ' - как для строк, но генерирует одиночный символ. u8'символ' - до сих пор не существовал, планируется ввести в будущем стандарте. Это тип char, перекодируется из кодировки исходников в UTF-8; если результат не влезает в char, то это ошибка компиляции (в отличие от соответствующего строкового литерала, где каждый символ имеет полное право занимать несколько char'ов в строке).
| |
|
5.14, BratSinot (ok), 12:05, 28/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Насчет размера до 6 не знал, каюсь. Тогда непонятно нафига нужны UTF-16 и UTF-32, если даже в UTF-8 5 и 6 байтов не используются.
| |
|
6.17, ананим.orig (?), 12:38, 28/02/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
Utf-16 и -32 — имеют фиксированный размер. "Придуманы" ДО utf8.
В последнем же переменный размер, например символы анси (английский алфавит как пример) занимает 1 байт, русский влазит в 2, китайский в 3,..
Например в жабе стандартная строка -16, думали что хватит, но современный юникод не влазит. Из-за чего у айзена и пoпaбoль. :D
В общем это легаси кодировки (по аналогии с 8-битными кодировками долго не думали, взяли и просто увеличили до 2-х байт, 4-х,.. потом поняли что что-то не так и придумали переменную длину. Старший бит определяет есть ли следующий байт или дальше уже другой символ идёт).
| |
|
7.19, ананим.orig (?), 12:57, 28/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
зыж
А вообще, читайте маны (если есть линух)
> $ man utf-8
там даже по-русски, подробно и, что важно, понятно. Например оттуда:
> Набор символов Unicode 3.0 занимает 16-битное кодовое пространство. Наиболее распространённая юникодная кодировка, известная как UCS-2, содержит последовательности 16-битных слов. Закодированные таким образом строки могут состоять из частей 16-битных символов например, '\0' или '/', которые имеют специальное значение в именах файлов и других параметрах функций библиотеки языка Си. Кроме того, большинство утилит UNIX предназначено для обработки ASCII-файлов и не может воспринимать 16-битные слова как символы. По этим причинам UCS-2 является неподходящей кодировкой Unicode для имён файлов, текстовых файлов, переменных окружения и т.д. Набор ISO 10646 Universal Character Set (UCS), расширенный набор Юникода, занимает более 31-битного кодового пространства, а используемая для него кодировка UCS-4 (последовательность 32-битных слов) имеет те же недостатки, что и описанные выше.
> Кодировка UTF-8 для представления Unicode и UCS лишена этих недостатков и поэтому в UNIX-подобных операционных системах используется наиболее часто.
.
| |
7.37, Crazy Alex (ok), 17:19, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
А вот не надо путать UCS-2 и UTF-16. Первый - фиксированного размера, но не все символы юникода в него влезают. Второй - переменного, как и UTF-8. UTF-32 - фиксированного размера, заведомо вмещает любой уникодный символ.
| |
|
8.43, амаима (?), 01:15, 01/03/2015 [^] [^^] [^^^] [ответить] | +1 +/– | Обе они переменного размера или 2 или 4 байта UCS-2 does not describe a data ... текст свёрнут, показать | |
|
|
6.18, Аноним (-), 12:44, 28/02/2015 [^] [^^] [^^^] [ответить] | +1 +/– | UTF-32 нужна потому, что в ней все символы занимают ровно по 32 бита Т е utf32... большой текст свёрнут, показать | |
|
7.25, Аноним (-), 14:52, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Зато UTF-8 компактнее и совместим с ASCII
А еще для работы с ним не надо переписывать программы... :)
| |
|
8.33, щщзы (?), 15:56, 28/02/2015 [^] [^^] [^^^] [ответить] | +2 +/– | Всё зависит от того, что вы делаете в программе Иногда - надо Как только встаё... текст свёрнут, показать | |
|
9.44, Аноним (-), 01:32, 01/03/2015 [^] [^^] [^^^] [ответить] | +/– | Но большнство кода системного, утилит, большинства либ - править не пришлось и... текст свёрнут, показать | |
|
|
7.35, Stax (ok), 16:26, 28/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> UTF-16 существует по историческим причинам
Ну, не надо так зарубать. UTF-16 - это основное и рекомендованное представление Unicode (рекомендованное именно консорциумом Unicode - не когда-то, а прямо сейчас), которое используется практически во всех серьезных проектах. В UNIX-системах популярен UTF-8, но он удобен только тогда, когда в саму строку не нужно вникать, а достаточно принять-передать ее: тут совместимость с ASCII рулит. Но любая обработка (нормализация, поиск и тд) в UTF-8 превращается в извращение.
По факту, даже в UNIX-системах серьезные проекты используют UTF-16 представление (Java, Python и т.д.). Что касается UTF-32, он, конечно, чуть удобнее, но ЖУТКО неэффективен - даже с учетом самых редких символов для кодирования всех определенных сейчас Unicode 7.0 символов достаточно 21 бита. С практической точки зрения же % символов, которые выходят из BMP совсем мал. Поэтому UTF-32 используют только те, кому лень написать простой if для выявления surrogate point'ов в UTF-16 (если уж совсем вручную обрабатывать, т.к. по факту в высокоуровневых языках поддержка есть внутри) и кому не жаль ради этого потратить в два раза больше памяти. Поэтому официально рекомендуется использовать UTF-16 представление везде, где требуется любая обработка строк, от UTF-32 держаться подальше, кроме представления отдельных символов (а не строк) - кстати, на практике так и делают, у того же питона в памяти UTF-16, но если попросить вывести представление одного символа, оно вернется как UTF-32 - и UTF-8 там, где нужна совместимость с ASCII и особо не требуется обработка.
| |
|
8.36, Аноним (-), 17:11, 28/02/2015 [^] [^^] [^^^] [ответить] | +/– | В Python используется не UTF-16, а wchar_t, который, между прочим, в винде UTF-1... текст свёрнут, показать | |
|
|
|
|
6.22, Аноним (-), 14:45, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
Перечитайте внимательно то, что я написал. _Строковый_ литерал u8"строка" я отнёс к категории "появился недавно", а _символьный_ литерал u8'символ' - будет в следующем стандарте.
| |
6.23, ананим.orig (?), 14:45, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
зыж
а да, пример:
> $ cat ./222.c
> #include <stdio.h>
> int main()
> {
> char s2[] = u8"a猫🍌 Пример — ☯ ☭ ☮";
> printf("u8\"%s\" is a char[%zu] holding \n ", s2, sizeof s2 / sizeof *s2);
}
> $ gcc -std=c11 -o 222 222.c
> $ ./222
> u8"a猫🍌 Пример — ☯ ☭ ☮" is a char[40] holding
главное -std=c11 не забывать
| |
|
7.45, Аноним (-), 01:33, 01/03/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
> главное -std=c11 не забывать
В свежих компилерах сам врубится. Вон у шланга говорят уже. Ну и у gcc будет, куда ж они денутся при конкуренции...
| |
|
|
9.49, Аноним (-), 15:40, 01/03/2015 [^] [^^] [^^^] [ответить] | +/– | В новости - о символьном литерале, которого ещё нет в стандартах, а приведённый ... текст свёрнут, показать | |
|
|
|
|
|
|
5.32, Аноним (-), 15:53, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
5 и 6 байт могут только теоретически (метод кодирования позволяет), практически в Юникоде не определено столько символов, чтобы потребовалось 5 или 6 байт в utf8.
| |
|
6.52, Crazy Alex (ok), 16:59, 01/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
А практически - если я увижу в коде, что он закладывается на то, что UTF8-символ не больше 4-х байт - он у меня ревью не пройдёт. Нефиг мины поддержке закладывать.
| |
|
7.67, Аноним (-), 22:37, 02/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
В таком случае советую обратить внимание на следующее.
UCS-2 способна представить символы с кодами до 2^16 (не включительно).
UTF-16 - до 2^20 + 2^16.
4-byte max UTF-8 - до 2^21.
полная UTF-8 - до 2^31.
UTF-32 - до 2^32.
(всё в порядке возрастания).
Т.е. если программа использует UTF-16 в качестве внутреннего представления (как некоторые тут рекомендовали) и перекодирует в него пользовательский ввод из UTF-8, то она вынуждена отвергать 5- и 6-байтные символы UTF-8 как непредставимые в UTF-16, а значит, по сформулированному вами критерию, не должна пройти у вас ревью.
| |
|
6.59, Аноним (-), 22:16, 01/03/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> 5 и 6 байт могут только теоретически (метод кодирования позволяет), практически в
> Юникоде не определено столько символов, чтобы потребовалось 5 или 6 байт
> в utf8.
Что ты, вихрь. Ты кантонский диалект видал?
| |
|
7.63, КО (?), 12:50, 02/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
>Что ты, вихрь. Ты кантонский диалект видал?
Укладывался он спокойно.
Вот, когда начали цветные смайлики кодировать...
| |
|
|
|
4.24, Аноним (-), 14:51, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Вы дурак, батенька. u8 это UTF-8!
У сишников u8 сроду означало unsigned integer, 8 битов.
| |
4.26, Аноним (-), 14:53, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Он может быть 1, либо 2 байта,
А японцы с их закорючками не в курсе - там и все 4 бывает...
| |
|
|
|
3.10, BratSinot (ok), 10:07, 28/02/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
> char и wchar_t?
char всегда 1 байт, wchar_t всегда 2, а u8 это литерал: u8"СтрокаASD".
| |
|
4.29, Аноним (-), 15:00, 28/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> char всегда 1 байт
Это не так. Стандарт определяет что "не менее 1 байта". Поэтому бывали чудесатые компилеры для DSP где char 16 битов. Потому что проц не умеет 8 битов адресовать и видит мир только 16-битными словами, хоть там что. Формально спеки не нарушает :).
| |
4.34, щщзы (?), 16:11, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> char всегда 1 байт, wchar_t всегда 2
по первой части - в зависимости от того, как определите байт (как 8 бит или как мин. адресуемая единица памяти) может быть верно или неверно. Верно, что sizeof(char) == 1.
по второй части - sizeof(wchar_t) == 4 на компьютере с которого пишу (x86_64 GNU/Linux).
| |
|
|
|
|
2.8, Andrey Mitrofanov (?), 09:12, 28/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> круто
> Цианогенмод когда на это попробует перейти?
Как тольто узнает что 1/ это "круто", 2/ уже надо переходить, так сразу, задрав штаны, и побежит. Отбей ему молнию!
| |
|
1.39, anonymous (??), 19:07, 28/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
> Применяемый по умолчанию режим языка Си изменён с C99 с расширениями GNU на C11 с расширениями GNU;
> с расширениями
А вот за такое бить нужно смертным боем.
| |
|
2.46, Аноним (-), 01:37, 01/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
> А вот за такое бить нужно смертным боем.
Так живых компилеров С по сути есть два. Шланг и гцц. Остальные где-то в ... - так что можно использовать сие и не беспокоиться. Извращенцы с вьюжлстудией и прочим крапом могут идти в пень: MS давно забил на си и даже во многом на плюсы, так что равняться на подобных ни к чему. У эппла свой objC и они как обычно сами по себе.
| |
|
|
4.53, Crazy Alex (ok), 17:01, 01/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
C и С++ не различаешь? Бывает.
Они не сподобились даже C99 под WinPhone сделать до сих пор.
| |
|
|
2.55, Аноним (-), 18:48, 01/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
Во-первых, за что именно? C11 или расширения GNU? Во-вторых, аргументируй. Про GNU ещё можно поспорить, но современный стандарт _обязан_ поддерживаться по умолчанию.
| |
|
1.42, Аноним (-), 23:53, 28/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Виртуальная машина - это виртуальная машина, - серьезно ответил программист, вставая,
- чуть быстрее, чуть медленнее - все едино, пропорции условны, а границы размыты. Я не святой, писал программы не только на ассемблере. Но
если мне приходится выбирать между java и c# - я предпочитаю не выбирать вовсе.
| |
1.62, Петруччо (?), 12:37, 02/03/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Значительно улучшена поддержка платформы Windows. Достигнут уровня самопересборки (self host) в окружении msvc на x86 и x64 системах Windows. Кроме исключений, поддержка Microsoft C++ ABI более-менее полностью реализована;
Наконец-то будут нормально собранные программы, и можно будет опять переходить на Windows!
| |
|
2.64, Andrey Mitrofanov (?), 13:08, 02/03/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Наконец-то будут нормально собранные программы, и можно будет опять переходить на Windows!
Не. Я бы посмотрел, как Эппле сдюжит тащить тот майкросовтовский "багаж". Ну, скажем 3-4 мажорнызх релиза этой их винды. Нельзя _так торопиться-то.
| |
|
|