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

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

Страницы: 1 2 3 4 5 6 7 Следующая »
#15
17:55, 10 июля 2018

что-то всё смешали

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

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

#16
18:01, 10 июля 2018

kipar
> Вопрос в том почему вместо них не использовать uint8_t\uint16_t\uint32_t или
> аналогичные.
Это что за типы?
С++ говорит, что

\Desktop\del-test\--sources--\RUSK.CPP|376|error: 'uint8_t' does not name a type|
#17
18:05, 10 июля 2018

122
#include <cstdint>

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

#18
18:07, 10 июля 2018

kipar
> #include
Ясно, очередной чей-то велосипед.

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

#19
18:10, 10 июля 2018

122
> Просто переименовали для красоты, что-ли?
  Это какбы разные типы данных и компилятор тебе об этом сообщит

#20
18:16, 10 июля 2018

122
да, для красоты, ну и чтоб не было путаницы с размерами. Для char это не актуально, а вот если нужен строго 32 или 64-битный тип то можно не гадать int\long\long long а брать int64_t.

#21
19:30, 10 июля 2018

Так в сях с самого начала char и был единственным способом задать байтовое целое число. Других способов и не было. См. K&R. Загадочно, что не сделали типа byte как раз отличного от char.

#22
19:52, 10 июля 2018

=A=L=X=
>Загадочно, что не сделали типа byte как раз отличного от char.
ну дык вполне понятно - 8 бит хватало всем, а вводить еще один тип, который будет отличатся только названием было впадлу.

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

#23
20:11, 10 июля 2018

Denadan
> библиотека же
Вот вот, библиотека.
А стандарт работает без библиотек, тому же int'у ведь не нужны библиотеки.

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

#24
(Правка: 20:18) 20:11, 10 июля 2018

=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 я не уточнял.

#25
20:29, 10 июля 2018

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

#26
(Правка: 20:30) 20:30, 10 июля 2018

122
> Это меня успокоило. Мне были интересны "short" и "int", и они сохраняют свои 16
> и 32 бита для всего актуального парка.
> А меняются они только для какого-то невероятно раритетного старья 15-20-30
> летней давности. Зачем его вообще вспоминают, непонятно.
На некоторых микроконтроллерах, 16-битный int актуален и сейчас.

#27
(Правка: 11 июля 2018, 0:09) 21:18, 10 июля 2018

Вообще-то арифметические операции над символами могут быть полезны:

bool isAlpha = ('a' <= ch && ch <= 'z') || ('A' <= ch && ch <= 'Z');

int digit = digitChar - '0';
#28
21:41, 10 июля 2018

ud1
Наверно, следовало написать, что имя "char" - это исторический артефакт, потому что сейчас символ=байт только у нубов и укурков.
В современном С++, char - это минимально адресуемая единица памяти, а для работы с байтами как с числами предназначены signed char и unsigned char.
Для символов текста же, если программист использует что угодно с диапазоном меньше, чем 0..0x10FFFF без веской на то причины - это не программист, а лох помойный.

#29
(Правка: 22:45) 22:44, 10 июля 2018

Зачем так категорично, 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.

Страницы: 1 2 3 4 5 6 7 Следующая »
ФлеймФорумПрограммирование