Тип переменной char

Объясните мне, что то я не понимаю, как я понял, этот тип общий, можно как писать, так вводить цифры, но почему то начиная с 10 программа выключается, также можно писать всего одну букву, но при этом даже русскую. Объясните мне, что из себя представляет этот тип. Я не могу понять, это такой тип который служит для ввода одного любого символа?

0

Сообщение от COKPOWEHEU Какое выравнивание переменных размером в один байт? Или я как-то не так понимаю термин aliasing?

Видимо, вы путаете aliasing и alignment.

COKPOWEHEU, я не зря спросил о strict aliasing. И дело здесь не в выравнивании. Если своими словами, то считается, что изменение данных одного типа не может влиять на данные другого типа, т.е.
clang 9.0.0 с опциями -std=c++2a -O3
Но для указателей на char сделано исключение, т.к. char предполагает работу с "голой" памятью:
Так вот, иногда это мешает оптимизации для других типов данных. В том числе при работе со строками. Вы работаете со строкой, которая никак не может повлиять на другие данные, но компилятор все равно считает, что вы работаете с сырыми байтами (не знаю как корректнее обозвать). И char8_t как раз призван решить эту проблемку - для него нет такого правила как для char.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU Про "подписанные символы" не слышал такого термина.

Наверное, машинный перевод слова signed.
Перепишем так:

Для обеспечения типа без знака для данных UTF-8 (независимо от того, является ли char знаковым или беззнаковым, что определяется реализацией).

0

Сообщение от COKPOWEHEU Чем оно лучше текущей реализации utf-8 на обычных char'ах?

Consider the following string literal expressions, all of which encode U+0123, LATIN SMALL LETTER G WITH CEDILLA:
The UTF-8, UTF-16, and UTF-32 string literals have well-defined and portable sequences of code unit values. The ordinary and wide string literal code unit sequences depend on the implementation defined execution and execution wide encodings respectively. Code that is designed to work with text encodings must be able to differentiate these strings. This is straight forward for wide, UTF-16, and UTF-32 string literals since they each have a distinct code unit type suitable for differentiation via function overloading or template specialization. But for ordinary and UTF-8 string literals, differentiating between them requires additional information since they have the same code unit type. That additional information might be provided implicitly via differently named functions, or explicitly via additional function or template arguments.

Сообщение от COKPOWEHEU Чем тут поможет перегрузка?

Странный вопрос, могу тебе работать с двумя типами "строк".

Сообщение от COKPOWEHEU Так проще char сделать беззнаковым по умолчанию. Кому надо сделают знаковым. Оно же и сейчас почти так.

Может поломать совместимость/чужой код.

Сообщение от COKPOWEHEU Про "подписанные символы" не слышал такого термина.

Это должны были быть знаковые и беззнаковые, гугл переводчик, блин )

Сообщение от COKPOWEHEU Какое выравнивание переменных размером в один байт?

Там идется не о alignment, a aliasing.

0

Сообщение от Croessmah Наверное, машинный перевод слова signed

Сообщение от Azazel-San гугл переводчик, блин

Угадал.

0

COKPOWEHEU, тут стоит понимать, что новый char8_t это не тот же тип что и unsigned char. Так же char8_t, в отличие от unsigned char нельзя использовать как underlying storage для объектов другого типа, а также для проверки базового представления объектов других типов; другими словами, его нельзя использовать для псевдонимов (alias) других типов. Следствием этого является то, что к объектам типа char8_t можно получить доступ через указатели на char или unsigned char, но указатели на char8_t нельзя использовать для доступа к данным char или unsigned char. Другими словами:
Добавлено через 4 минуты

0

0

Сообщение от elenayagubova В этом примере я бы то же самое говорила при использовании спецификатора %c - нельзя получить с его помощью число, введенное с клавиатуры.

Вот это уже неудачный пример, поскольку %c - специальный формат для символа, а не числа.

Сообщение от Croessmah Видимо, вы путаете aliasing и alignment.

действительно спутал.

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

Так вроде ж есть специальные модификаторы, кажется в memcpy используются иногда, тоже для оптимизации.

Сообщение от Azazel-San Странный вопрос, могу тебе работать с двумя типами "строк".

Опять гуглопереводчик? При вводе любая строка преобразуется к внутреннему представлению (wchar_t скорее всего) и дальше работа идет только в нем. Та же utf-8 хорошо подходит для хранения, но не обработки. Ну а если национальных букв не предполагается, то и ADCII (char*) хватит.

Сообщение от Azazel-San Может поломать совместимость/чужой код.

Если этот "чужой код" полагался на знаковость-беззнаковость char'а, то он изначально поломан, поскольку стандарт этого не гарантирует. То есть "более поломанным" он не станет. Да и -fsigned-char / -funsigned-char никто не отменял. Хотя с ужесточением стандарта хорошо бы выводить предупреждение. Впрочем, сама неопределенность знака в char непонятна: какой смысл может нести отрицательный код символа?!

Сообщение от Azazel-San Там идется не о alignment, a aliasing.

Тем более. Aliasing же не привязан к типу данных. Можно и для int гарантировать "неперекрытие".

Сообщение от Azazel-San его нельзя использовать для псевдонимов (alias) других типов

Хотят сделать более строгую типизацию что ли? И тем самым поломать оптимизации? А смысл?

0

Сообщение от COKPOWEHEU Так вроде ж есть специальные модификаторы, кажется в memcpy используются иногда, тоже для оптимизации.

Вы о restrict? В C он есть, а в C++ нет. И не спрашивайте почему, мне тоже это интересно. )

0

Сообщение от COKPOWEHEU Вот это уже неудачный пример, поскольку %c - специальный формат для символа, а не числа.

Но примерно такую же ошибку делает человек, пытающийся с помощью ввода из потока ввести число в char. Результат, во всяком случае, одинаковый - в char записывается первый символ, остальные остаются в потоке.
Я, конечно, не очень удачно сформулировала свое сообщение про невозможность ввода числа в char(зато дискуссия ушла в интересное русло ), но отвечала исключительно на попытку HOBUchEK ввести "10" в качестве символа и предположение ReYalp о том, что в этом случае введется символ, соответствующий числу(коду) 10.

0

Сообщение от COKPOWEHEU При вводе любая строка преобразуется к внутреннему представлению (wchar_t скорее всего) и дальше работа идет только в нем.

Причем здесь вообще ввод? Вы читали, что я вам писал?

Сообщение от COKPOWEHEU Если этот "чужой код" полагался на знаковость-беззнаковость char'а, то он изначально поломан, поскольку стандарт этого не гарантирует.

Зачем менять char? В чем смысл? Если можно получить более строгую типизацию.

Сообщение от COKPOWEHEU Тем более. Aliasing же не привязан к типу данных. Можно и для int гарантировать "неперекрытие".

Тем, что char перекрывается со всеми типами.

Сообщение от COKPOWEHEU Хотят сделать более строгую типизацию что ли? И тем самым поломать оптимизации? А смысл?

Какие оптимизации? О чем вы? Это наоборот улучшает оптимизацию.

0

Сообщение от Azazel-San Причем здесь вообще ввод? Вы читали, что я вам писал?

Сообщение от Azazel-San Странный вопрос, могу тебе работать с двумя типами "строк".

Я пытался перевести это на человеческий язык, но, похоже, не преуспел.

Сообщение от Azazel-San Зачем менять char? В чем смысл? Если можно получить более строгую типизацию.

Именно для этого. Чтобы получить более строгую типизацию и не плодить сущности.

Сообщение от Azazel-San Тем, что char перекрывается со всеми типами.

Любой другой 8-битный тип точно так же будет перекрываться. В чем разница?

0

COKPOWEHEU, в том, что char8_t не перекрывается со всеми, как обычный char. Как и впрочем нету гарантии что он будет именно 8 бит занимать.

Ну и если хотим более строгую типизацию, без плождения сущностей не обойтись.

0

А компилятор с ума не сойдет от таких преобразований? Проверил: действительно сойдет: C++ 1 2 3 4 5 6 7 8 9 10 11 #include <stdio.h> #include <iostream>   int main(int argc, char **argv){   char a = 100;   char b = 50;   char c = 42;   printf("%hhi %hhi %hhi\n", a, b, c);   std::cin >> *(int*)&b;   printf("%hhi %hhi %hhi\n", a, b, c); } Code 1 2 3 4 5 $ g++ main.c -Wall $ ./a.out 100 50 42 123 0 123 0 Самое забавное, что ваш код портит переменные по обе стороны от целевой. Я думал, только с одной будет. Но выравнивание - штука страшная.

Компилятору то что, он парень простой, сказали скомпилировать, они и сделал, а вот аллоктору, тому да, досталось.

0

нужно знать только одно char это один байт, а писав cin>>ch; вы просто говорите прочесть с клавиатуры символ и написав например 1 и нажав на энтер вы говорите засунуть в эту переменную 0x31

0

Сообщение от Azazel-San char8_t <...> нету гарантии что он будет именно 8 бит занимать.

Серьезно?! То есть они назвали тип по аналогии со стандартными типами фиксированного размера и не гарантируют размер?! Не говоря уж о том, что для символа UTF-8 стоило бы и тип назвать вроде utf8_t.
Не говоря уж о том, что символ UTF-8 штука переменной длины, от 8 до 32 бит, то есть в одну обычную переменную Си/С++ не влезет: либо там будет огрызок символа, бесполезный сам по себе, либо будет клон wchar_t. Хотя если сделать по принципу void (запретить разыменование и создание переменных не-указателей) может и имеет смысл... Хотя все равно пложение сущностей без необходимости.
Собственно, логичнее было бы делать не Си-подобную переменную, а сразу строковый объект со всеми необходимыми методами и преобразованиями в char*, wchar_t*, std::string, std::wstring.
В общем, непонятно зачем вводить еще один uint8_t с каким-то собственным назначением.

0

Сообщение от COKPOWEHEU стоило бы и тип назвать вроде utf8_t

Ну, да, вот с названием согласен.

Сообщение от COKPOWEHEU а сразу строковый объект со всеми необходимыми методами и преобразованиями

Будет и std::string под это.

0

Сообщение от COKPOWEHEU В общем, непонятно зачем вводить еще один uint8_t с каким-то собственным назначением.

Пичалька.

0