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

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

Страницы: 1 2 3 4 5 6 7 Следующая »
clcПостоялецwww10 июля 201817:55#15
что-то всё смешали

строка - это структурный тип
символ - как char не вызывал вопросов пока всё было в ascii, сейчас это вариативный тип или даже виртуальный (например из-за лигатур)

вопрос про размер символа отпадёт, если попытаться написать свой вариант
готовы отдать под символ 4 байта? это означает что какой-либо файл вырастет с 1 гига до 4 гигов, к примеру

122Постоялецwww10 июля 201818:01#16
kipar
> Вопрос в том почему вместо них не использовать uint8_t\uint16_t\uint32_t или
> аналогичные.
Это что за типы?
С++ говорит, что
\Desktop\del-test\--sources--\RUSK.CPP|376|error: 'uint8_t' does not name a type|
kiparУчастникwww10 июля 201818:05#17
122
#include <cstdint>

Я понимаю что в старом С и С++ их не было и соответственно выбора тоже не было, дали char используй char. Но авторов новых языков это не оправдывает.

122Постоялецwww10 июля 201818:07#18
kipar
> #include
Ясно, очередной чей-то велосипед.

Но тогда вопрос: нафига, если этот uint8_t просто #define с ансигнед чара?
То есть для компилятора это ансигнед чар и будет.
Просто переименовали для красоты, что-ли?

равенПостоялецwww10 июля 201818:10#19
122
> Просто переименовали для красоты, что-ли?
  Это какбы разные типы данных и компилятор тебе об этом сообщит
kiparУчастникwww10 июля 201818:16#20
122
да, для красоты, ну и чтоб не было путаницы с размерами. Для char это не актуально, а вот если нужен строго 32 или 64-битный тип то можно не гадать int\long\long long а брать int64_t.
=A=L=X=Постоялецwww10 июля 201819:30#21
Так в сях с самого начала char и был единственным способом задать байтовое целое число. Других способов и не было. См. K&R. Загадочно, что не сделали типа byte как раз отличного от char.
DenadanПостоялецwww10 июля 201819:52#22
=A=L=X=
>Загадочно, что не сделали типа byte как раз отличного от char.
ну дык вполне понятно - 8 бит хватало всем, а вводить еще один тип, который будет отличатся только названием было впадлу.

122
стандартная библиотека же. впрочем "очередной чей-то велосипед" отлично описывает с++, но это уже совсем другой разговор.

122Постоялецwww10 июля 201820:11#23
Denadan
> библиотека же
Вот вот, библиотека.
А стандарт работает без библиотек, тому же int'у ведь не нужны библиотеки.

kipar
> а вот если нужен строго 32
А для каких систем int автоматически считается за 64 бита?
Вроде для x86-64 нет такого, инт всегда 32.

DelfigamerПостоялецwww10 июля 201820:11#24
=A=L=X=
> Загадочно, что не сделали типа byte как раз отличного от char.
Оперативную память экономили, очевидно же.

122
> А для каких систем int автоматически считается за 64 бита?
https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
От себя ещё добавлю CellOS lv2, которая стоит на PS3. Там сам процессор работает в 64-битном режиме - то есть, как минимум будет 64-битный long long; однако, виртуальная память настроена на 32-битные указатели, опять же ради экономии памяти консольки.
То есть, на ней, sizeof(int) == sizeof(void*) == sizeof(size_t) == 4, sizeof(long long) == 8, а размер long я не уточнял.

Правка: 10 июля 2018 20:18

122Постоялецwww10 июля 201820:29#25
Delfigamer
> 64-bit_computing#64-bit_data_models
Спасибо.
Это меня успокоило. Мне были интересны "short" и "int", и они сохраняют свои 16 и 32 бита для всего актуального парка.
А меняются они только для какого-то невероятно раритетного старья 15-20-30 летней давности. Зачем его вообще вспоминают, непонятно.
DelfigamerПостоялецwww10 июля 201820:30#26
122
> Это меня успокоило. Мне были интересны "short" и "int", и они сохраняют свои 16
> и 32 бита для всего актуального парка.
> А меняются они только для какого-то невероятно раритетного старья 15-20-30
> летней давности. Зачем его вообще вспоминают, непонятно.
На некоторых микроконтроллерах, 16-битный int актуален и сейчас.

Правка: 10 июля 2018 20:30

ud1Постоялецwww10 июля 201821:18#27
Вообще-то арифметические операции над символами могут быть полезны:
bool isAlpha = ('a' <= ch && ch <= 'z') || ('A' <= ch && ch <= 'Z');
int digit = digitChar - '0';

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

DelfigamerПостоялецwww10 июля 201821:41#28
ud1
Наверно, следовало написать, что имя "char" - это исторический артефакт, потому что сейчас символ=байт только у нубов и укурков.
В современном С++, char - это минимально адресуемая единица памяти, а для работы с байтами как с числами предназначены signed char и unsigned char.
Для символов текста же, если программист использует что угодно с диапазоном меньше, чем 0..0x10FFFF без веской на то причины - это не программист, а лох помойный.
ud1Постоялецwww10 июля 201822:44#29
Зачем так категорично, utf-8 гармонично ложится на однобайтный char. До тех пор, пока не надо обращаться к отдельным символам, char работает замечательно, идеально подходит для хранения и передачи строк. Можно даже конкатенировать строки. Да и метод contains /indexOf тоже будет работать.
К отдельным символам в utf-8 в принципе тоже обращаться легко, только это будет скорей всего в виде forward итератора, а не random access итератора, что для большинства задач думаю достаточно.
Вот substring по индексам не удобно будет делать. Но вопрос, зачем вообще может понадобится в программе substring? Над текстом содержащим произвольные символы? В голову ничего не приходит.
Вот если например у нас есть путь к файлу, мы хотим проверить, что путь начинается с определенной директории, и потом вырезаем эту директорию из пути:
  if (str.startsWith(someDir))
    subdir = str.substring(someDir.size());
то и это без проблем будет работать с обычными char'ами с utf-8.

Или например хотим сделать split пути по слэшам, "a/b/c", то и это тоже должно прекрасно работать с utf-8.

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

В общем, если подумать, то требования использовать что-то шире чем char малообоснованны. Иметь random access iterator по строке нужно только если делаешь реально нетривиальные преобразования над символами, а это большая редкость, разве что для NLP программ тесно работающим с текстом. Старые программы на сишке вполне должны справляться с utf-8 без какого-либо допиливания.

Тут майкрософт всю эту тему с utf-8 запорол, когда в WinAPI задублировал все методы со строками на "A" и на "W" варианты, причем вариант с "A" сделал убогим, не умеющим в utf-8, заставляя использовать "W" методы, что несовместимо с методами сишной стандартной библиотеки, типа fopen, и тем самым превратив кросплатформенную работу с поддержкой юникода в ад. Неудивительно, что даже сегодня я замечаю проблемы с поддержкой юникода в виндовых программах, чего ни разу не видел в том же линуксе.

Т.е. в линуксах метод fopen, придуманный десятилетия назад, еще до рождения винды может работать с путями заданными в utf-8, а метод CreateFileA по каким-то причинам не может. Просто абсурд. Только сейчас понял, почему MS сделало такой абсурдный шаг, видимо из-за того, что они придумали делать имена файлов регистронезависимыми, тем самым каждый раз вызывая CreateFile винда должна делать трюки с преобразованием регистра символов, что совсем нетривиальная задача. В общем они сами придумали себе геморой, и теперь одни архитектурные ошибки тянут за собой другие. Интересно сколько тысяч человеко лет было потрачено в пустую человечеством, на борьбу с тем, что разделители в путях у MS это обратный слеш вместо прямого, и что перевод строки в тексте это \r\n вместо нормального \n.

Правка: 10 июля 2018 22:45

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

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

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