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

char - зачем?

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

Во многих современных языках есть фундаментальный тип "char":

В крестах это "char" на один байт а также "wchar_t" в два или четыре байта.
В Java/C# есть char из двух байт.
В D есть аж три - char, wchar, dchar.
В Rust есть char, и он четырёхбайтный. При этом строки хранятся в UTF-8 как вектора из однобайтных элементов.

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

#1
15:18, 10 июля 2018

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

#2
15:45, 10 июля 2018

char, wchar, int (UTF8)
ух, заживем!
Вообще это было нужно для оптимизации данных. Больше ничего. Не всё же в лонгах хранить

#3
15:54, 10 июля 2018

Panzerschrek[CN]
> а просто использовать типы фиксированной ширины для представления символов?
Я согласен (на самом деле нет).
Какую ширину предложишь?

#4
15:56, 10 июля 2018

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

lookid
Вопрос в том почему вместо них не использовать uint8_t\uint16_t\uint32_t или аналогичные.

#5
16:07, 10 июля 2018

Panzerschrek[CN]
> Вопрос - а нафига они все нужны?
А чтоб не забывали и не теряли живой связи с традицией. И я это говорю почти серьёзно.

#6
(Правка: 16:18) 16:13, 10 июля 2018

kipar
> Вопрос в том почему вместо них не использовать uint8_t
int8_t, еретик

Холивар же пойдет. "Зачем использовать unsigned, если Java"
#7
16:17, 10 июля 2018

kipar
> Вопрос в том почему вместо них не использовать uint8_t\uint16_t\uint32_t или
> аналогичные.
Потому что uint8_t числовой тип, а char - строчный.
Это просто так совпало, что один можно представить другим и наоборот.

#8
16:24, 10 июля 2018

Great V.
Ну, типа того. Случайно так совпало что авторы языков ориентировались на сишку и потому не смогли нормальный строчный тип сделать.

#9
(Правка: 16:43) 16:40, 10 июля 2018

Panzerschrek[CN]
> При этом строки хранятся в UTF-8 как вектора из однобайтных элементов

Ты ещё скажи, что любой тип данных хранится в памяти как вектор из однобайтных элементов, а потому типы данных не нужны. И пусть программисты сами голову ломают, где какой тип используется. Онижпрограммисты.
И вообще языки высокого уровня не нужны. Все равно же любой код в ассемблер компилируется.

#10
(Правка: 17:15) 17:00, 10 июля 2018

Great V.
> Какую ширину предложишь?
Какую захочешь. Можно в UTF-8, можно в UTF-16, можно в UTF-32.

Sbtrn. Devil
> А чтоб не забывали и не теряли живой связи с традицией. И я это говорю почти
> серьёзно.
Да, есть такое, инерционность мышления + необходимость совместимости.

Great V.
> Потому что uint8_t числовой тип, а char - строчный.
Это было бы так, если бы к символьному типу нельзя было применять арифметические операции.
А так выходит, что все эти char-типы - фуфло.

Betruger
> И вообще языки высокого уровня не нужны.
Как раз нужны, и типизация нужна.
Меня вот только интересует вопрос символьных типов - они какие-то странные.

#11
(Правка: 17:31) 17:30, 10 июля 2018

Panzerschrek[CN]
> Это было бы так, если бы к символьному типу нельзя было применять
> арифметические операции.
А в той самой древней сишечке разве был тип, для работы с байтом-числом?
Совместили приятное с полезным, корочи. Да, не очень системно. Но что поделаешь, то были другие времена.

> Какую захочешь.
Ну вот. Захотеть можно по разному, потому и существуют все эти типы.

#12
17:40, 10 июля 2018

Я напомню, что char, signed char и unsigned char - это 3 разных типа.
Оно выглядит в тему.

#13
17:42, 10 июля 2018

Panzerschrek[CN]
> Это было бы так, если бы к символьному типу нельзя было применять
> арифметические операции.

Ага. Использование арифметических операций для шифрования строк - это неполиткорректно же. Роскомнадзор запретил )

#14
17:51, 10 июля 2018

Betruger
Что UTF-8, что UTF-32 строка после шифрования станет невалидным куском байтов. Поэтому да, шифровать строки неполиткорректно и вообще говнокод. Шифровать надо либо нетипизированные буферы (с точки зрения вызывающей программы) либо массивы чисел (с точки зрения алгоритма).

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