Флейм
GameDev.ru / Флейм / Форум / char - зачем? (3 стр)

char - зачем? (3 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
9К720Участникwww10 июля 201823:14#30
Great V.
> Это просто так совпало, что один можно представить другим и наоборот.
Нельзя представить один другим и наоборот. То что в крестах нет нормальной типизации, не повод считать чар целым.
DelfigamerПостоялецwww10 июля 201823:26#31
ud1
> До тех пор, пока не надо обращаться к отдельным символам
Именно. Один байт utf-8 != один символ. Символ текста - это int. Байт строки - это char.
А строки можно хранить в чём угодно, хоть utf-32+deflate. Просто utf-8 выделился тем, что в нём некоторые операции можно делать без перекодирования, ибо он изначально разрабатывался таковым.
Ну и как следствие, строка в utf-8 != массив символов, на что, как бы, намекает и само название технологии - "кодировка".

Так что если в
> bool isAlpha = ('a' >= ch && ch <= 'z') || ('A' >= ch && ch <= 'Z');
> int digit = digitChar - '0';
ch или digitChar - это char, то программист, в общем случае, всё-таки мохнатый лох.

Delfigamer
> От себя ещё добавлю CellOS lv2, которая стоит на PS3. Там сам процессор
> работает в 64-битном режиме - то есть, как минимум будет 64-битный long long;
> однако, виртуальная память настроена на 32-битные указатели, опять же ради
> экономии памяти консольки.
> То есть, на ней, sizeof(int) == sizeof(void*) == sizeof(size_t) == 4,
> sizeof(long long) == 8, а размер long я не уточнял.
Вот, господа, я ради вас даже специально скачал секретный PS3 SDK с торрентов и заглянул в заголовочники:

+ Показать

Правка: 10 июля 2018 23:27

ud1Постоялецwww10 июля 201823:35#32
Delfigamer
Ну так ты и не объяснил, зачем тебе обращаться к строкам как с массивом символов? Чем массив байт не подходит?
В общем не морочьте голову, и используйте обычный char.
DelfigamerПостоялецwww10 июля 201823:42#33
ud1
> Ну так ты и не объяснил, зачем тебе обращаться к строкам как с массивом
> символов? Чем массив байт не подходит?
> В общем не морочьте голову, и используйте обычный char.
Я объясняю, что нельзя обращаться с char, как с символами. В том числе, char нельзя проверять на буквы и переводить в цифры, вопреки тому, что подразумевается в #27.
ud1Постоялецwww10 июля 201823:58#34
Delfigamer
Почему нельзя? Если нужно найти в utf-8 строке латинские символы, или числа, то предложенный способ будет прекрасно работать.

В utf-8 у нас могут быть как ascii так и не ascii символы. Ascii будут занимать один байт, и тем самым с ними можно делать что угодно. Главное не задевать байты относящиеся к не ascii символам, но для этого никаких дополнительных умений не нужно, так как их диапазоны и так не пересекаются - у ascii старший бит 0, а у других 1. Тем самым если я беру utf-8 строку, и вызываю для каждого байта isDigit = '0' <= ch && ch <= '9', то я не могу ошибиться, и принять не число за число, так как в не ascii символах подобный диапазон значений быть не может.

Правка: 11 июля 2018 0:09

DelfigamerПостоялецwww11 июля 20180:21#35
ud1
А для чего может понадобиться найти в utf-8 строке латинские символы или числа?
Если ты пишешь парсер для какого-нибудь json-а и разбираешь его побайтно - то не нужно употреблять термин "UTF-8" там, где он не при делах. Если парсер побайтовый - то он отработает на любых текстах, которые соответствуют ожидаемой парсером структуре, включая и UTF-8, и ASCII, и 1251, и даже невалидную кракозябрину с неспаренными суррогатами; а вот Shift-JIS он, скорее всего, не распарсит; а ещё, скорее всего, UTF-8 w/ BOM он не поймёт, и сверхдлинные коды он не воспримет. И это, на самом деле, будет хорошо - пусть он пропускает валидный utf-8 как есть и не пытается быть умнее, чем нужно, ибо бардака с кодировками уже и так хватает в C++.
Если же ты работаешь с человеческим текстом и ищешь слова в веб-странице по пользовательскому запросу - проще взять готовую библиотеку; но если же вдруг приспичило писать велосипед - передача отдельных символов через char или short не даст ничего, кроме головной боли и проблем, когда пользователь захочет найти в тексте эмодзи, музыкальные символы и раскрашенные формулы.

Правка: 11 июля 2018 0:23

122Постоялецwww11 июля 20180:33#36
ud1
> чего ни разу не видел в том же линуксе.
> вместо нормального
Вот бы сейчас линукс рассматривать как норму.
По стимсурвею линукса у игроков - 0.52%.

ud1
> в WinAPI
> метод fopen
> utf-8
Для работы с файлами utf-8 - не нужен. Все замечательно хранится в аски.
Сложности и переменное количество байт только чтобы в названиях файлов писать смайлики - глупо. Имхо.

Втройне глупо это тащить в стандарт языка, это должно быть на уровне внешнего апи и стандартов языка не касаться. В стандарте языка должны быть ячейки различного размера: 8,16,32 и так далее бит. А что в них хранить уже дело программы. Снова имхо.

DelfigamerПостоялецwww11 июля 20183:08#37
122
Не такое уж плохое имхо, на самом деле - NTFS как формат хранит имена файлов в массивах 16-битных слов без придания какого бы то ни было смысла их содержанию.
Драйвер NTFS в винде же ради регистронезависимости производит преобразования, если мне не изменяет память - для идентификации все ячейки с "буквами" переводятся в верхний регистр, а оригинальная запись сохраняется неподалёку для листингов в dir, проводнике и прочих браузерах.
Но опять же - если в имя файла завернуть неспаренный суррогат, кернел в ус не дунет и так файл и запишет. Если постараться - можно и пробелов по обеим сторонам понаставить, и оно даже будет как будто бы работать в нормальном режиме - "D:\g\a.txt" открывает один файл, "D:\g\ a.txt" - совсем другой.
А интерпретация этого дела как UTF-16 происходит уже в юзерспейсе - это делает CreateFileA (хоть какое-то соответствие должно же быть, вот они и взяли текущая_локаль<->UTF-16) и это делает Проводник (чтобы отрендерить строку на экране).

В линуксе, скорее всего, ещё проще, раз там даже регистрами заморачиваться не нужно - пропустил байты как они есть, сравнил, открыл.
А то, что эта система вдруг работает с utf-8 - так это же utf-8 специально подстраивали, чтобы он был обратно совместим с вот такими незамысловатыми системами.

KartonagnickЗабаненwww11 июля 201813:41#38
char вполне достаточно для решения 99,(9)% всех задач со строками.
оставшийся 0,(1)% wchar_t не спасет -> на откуп специализированным библиотекам.
которые умеют в нормализацию и прочие такие национальные приколы.

вывод: wchar_t и компания - не нужны.

Delfigamer
> В том числе, char нельзя проверять на буквы и переводить в цифры, вопреки тому,
> что подразумевается в #27.

то есть, код рабочий, но так делать нельзя?
чо за бред?

Правка: 11 июля 2018 13:41

Panzerschrek[CN]Участникwww11 июля 201813:47#39
Kartonagnick
> вывод: wchar_t и компания - не нужны.
А если я захочу кириллицу хранить, то сразу стороннюю библиотеку тащить?
KartonagnickЗабаненwww11 июля 201814:04#40
Panzerschrek[CN]
> А если я захочу кириллицу хранить, то сразу стороннюю библиотеку тащить?
храни, какие проблемы?

Panzerschrek[CN]Участникwww11 июля 201814:56#41
Kartonagnick
> храни, какие проблемы?
Просто "хранить" кириллицу в char не выйдет, нужно utf-8 или что-то подобное использовать.
Или ты предлагаешь использовать богопротивную windows1251?
KartonagnickЗабаненwww11 июля 201815:02#42
Panzerschrek[CN]
> Просто "хранить" кириллицу в char не выйдет, нужно utf-8 или что-то подобное
> использовать.
используй utf-8.
в чем проблема то?

kiparУчастникwww11 июля 201815:17#43
Panzerschrek[CN]
просто пока программе не надо ни отображать текст, ни считывать пользовательский ввод, можно спокойно использовать строки char и не заботиться о utf-8. Поиск подстроки работает и ладно.
Panzerschrek[CN]Участникwww11 июля 201815:23#44
Kartonagnick
> используй utf-8.
> в чем проблема то?

kipar
> просто пока программе не надо ни отображать текст, ни считывать
> пользовательский ввод, можно спокойно использовать строки char

Проблема только в том, что "char" теряет свою семантику. Вместо типа, хранящего символы, он является типом, хранящим байты utf-8 строк. В кроестах это ещё и тип, над которым зачем-то можно ещё и арифметические операции проводить.

Меня бы больше устроил тип с несколько другим именем и без возможности арифметических операций.

Страницы: 1 2 3 4 5 6 7 Следующая »

/ Форум / Флейм / Программирование

2001—2018 © GameDev.ru — Разработка игр