Зачем использовать ASCII-код для букв алфавита в операторах if вместо использования обычного символьного типа данных?

Я читаю несколько строк кода, написанного коллегой, и он написал код следующим образом:Зачем использовать ASCII-код для букв алфавита в операторах if вместо использования обычного символьного типа данных?

int keych = 0; 
keych = _getch(); 
if (keych == 104 || keych == 104 - 32) //Help 
{ 
    printf(cHelp); 
}

Что я do'nt понимаю, что почему он не использует простой тип данных CHAR, это помогает напишите меньше кода. В чем преимущества использования этого метода вместо типа данных char для ввода пользователя?

источник

2017-02-21 Samir

Что этот вопрос имеет отношение к Unicode? –

Нет никаких преимуществ. Скомпилированный код точно такой же. Ваш коллега не очень опытен. Использование обычных символов делает сразу же очевидным, что это происходит, если только вы не запоминаете код ascii для каждого символа. Написание '' '' гораздо более значимо, чем таинственное число 32. –

@nicol bolas, потому что оператор if принимает символы Unicode, например. 104 - это буква «h» для помощи. Думаю – Samir

Использование

if (keych == 104 || keych == 104 - 32) //Help

, чтобы решить, является ли входной символ 'h' или 'H' плохо.

Трудно читать.
Он будет работать только на системах, которые используют 104 и 72 для кодирования h и H (например, ASCII).

Это будет лучше использовать:

if (keych == 'h' || keych == 'H')

или

if (tolower(keych) == 'h')

источник

2017-02-21 16:31:27

«Только ASCII», возможно, является чрезмерным упрощением - существует множество кодировок, которые имеют «h» и «H» в том же положении, что и в ASCII, например, в кодировке ISO 8859. Важно то, что существуют кодировки, в частности EBCDIC, которые имеют разные назначения для этих символов. –

@TobySpeight - и, несмотря на комментарии в ответ на вопрос, кодовые точки Unicode, значения которых меньше 128, представляют собой те же символы, что и ASCII. –

Oups, Юникода и ASCII не совсем то же самое, или более точно ASCII является подмножеством Unicode (127 первых кодовых пунктов). 104 или (0x98 в гекса) - код ASCII для «h», поэтому здесь не задействован unicode. Единственным достоинством использования кода ascii является то, что он будет разбит на систему без ASCII, и все еще может быть система EDCDIC вокруг ... и дополнительно, как вы сказали в комментарии, 104 более загадочно, чем «h».

TL/DR: никогда не заменяйте символы своей кодовой точкой ascii, если у вас нет серьезных оснований для этого.

источник

2017-02-21 16:32:10

Это хорошая практика, если не очень интуитивно понятна для новичков, чтобы хранить переменные символов и передавать их как int. Стандартная библиотека делает это, fputc() принимает и int не char. В C sizeof ('a') дает 2 или 4 в зависимости от размера int, а не 1 для sizeof (char).

Причина в том, что int может содержать EOF, который не является символом и означает конец ввода или состояние ошибки. Существует также эффект, что код масштабируется до unicode довольно хорошо.

источник

2017-02-21 16:45:56

Единственный раз, когда разумно обращаться к (печатаемым) символам с помощью кодовых точек в кодировке, когда вы знаете, что данные, которые вы обрабатываете, не в родной форме для вашей программы - это, скорее всего, реализуя преобразование кода, либо как программу, например iconv, либо как уровень конверсии в классах ввода/вывода вашей программы. Обычно вам не нужно писать такие вещи самостоятельно; для чего нужны библиотеки.

Даже если вы пишете конверсии, это помогает указывать имена для значений, которые вы используете, например.

static const int UNICODE_LATIN_SMALL_LETTER_H = 0x68;

В частном случае в вопросе, считая, что _getch() является чем-то вроде проклятий getch(), то вы должны ожидать, что она будет представлена последовательно с константами символов в исходной программе набора вашего персонажа.

источник

2017-02-21 16:49:56

Зачем использовать ASCII-код для букв алфавита в операторах if вместо использования обычного символьного типа данных?

ответ

Смежные вопросы