Почему шестнадцатеричные числа с префиксом 0x?

Question

Почему шестнадцатеричные числа с префиксом 0x?

285

Почему шестнадцатеричные числа префиксны как 0x? Я понимаю использование префикса, но я не понимаю значения того, почему был выбран 0x.

unj2 19 апр. 2010, в 20:57

Источник

7

Теперь я понимаю, что заголовок и текст задают два совершенно разных вопроса. Большинство ответов сосредоточены на вопросе в заголовке. Ответ на вопрос в тексте просто «это ничего не значит - это просто префикс, сообщающий компилятору, что целое число записано в шестнадцатеричном формате».
Andreas Rejbrand 22 апр. 2010, в 23:39
25

Чтобы быть педантичным, можно также интерпретировать вопрос в названии двумя различными способами: 1) «Почему шестнадцатеричные числа имеют префикс 0x, а не любой другой префикс или индикатор?» 2) «Почему мы должны использовать префикс при вводе шестнадцатеричных чисел? Конечно, компилятор распознает 58A как шестнадцатеричное число даже без префикса?» Ответ на второе толкование вопроса тривиален. «123» также является шестнадцатеричным числом.
Andreas Rejbrand 22 апр. 2010, в 23:42

Теги:

c

hex

syntax

4 ответа

85

Примечание: я не знаю правильного ответа, но ниже это только мои личные предположения!

Как уже упоминалось, 0 перед номером означает его восьмеричное:

04524 // octal, leading 0

Представьте себе, что нужно придумать систему для обозначения шестнадцатеричных чисел, и обратите внимание, что мы работаем в среде стиля C. Как насчет окончания с h как сборка? К сожалению, вы не можете - это позволит вам делать токены, которые являются действительными идентификаторами (например, вы могли бы назвать переменную одинаковой), что сделало бы для некоторых неприятных двусмысленностей.

8000h // hex
FF00h // oops - valid identifier!  Hex or a variable or type named FF00h?

Вы не можете привести с символом по той же причине:

xFF00 // also valid identifier

Использование хэша, вероятно, было выброшено из-за конфликта с препроцессором:

#define ...
#FF00 // invalid preprocessor token?

В конце концов, по какой-то причине, они решили поставить x после того, как ведущий 0 обозначил шестнадцатеричный. Он недвусмыслен, так как он все еще начинается с символа числа, поэтому не может быть допустимым идентификатором и, вероятно, основан на восьмеричном соглашении ведущего 0.

0xFF00 // definitely not an identifier!

AshleysBrain 19 апр. 2010, в 21:28

3

Интересно. Я предполагаю, что они могли использовать начальный 0 и конечный h, чтобы обозначить гекс. Конечный h, вероятно, был бы перепутан с суффиксом спецификатора типа, например, 0xFF00l против 0FF00hl
zdan 20 апр. 2010, в 00:24
2

Этот аргумент подразумевает, что использование начального нуля для обозначения восьмеричных чисел предшествует использованию шестнадцатеричного префикса «0x». Это правда?
Andreas Rejbrand 22 апр. 2010, в 13:09
1

Разве они не были изобретены одновременно? Почему когда-либо будет один, а не другой?
AshleysBrain 22 апр. 2010, в 13:28
0

AshleysBrain см. Ответ @ Řrřola о том, почему может быть восьмеричное, но не шестнадцатеричное в одно и то же время.
jv42 27 янв. 2012, в 09:11
2

@zdan они использовали это давным-давно. В сборке Intel x86 шестнадцатеричный литерал всегда должен начинаться с 0, если они начинаются с символа. Например, 0xFFAB1234 должно быть записано как 0FFAB1234h . Я помню это из встроенного ассемблера в Паскале, когда я был молодым stackoverflow.com/q/11733731/995714
phuclv 11 окт. 2015, в 03:34
0

Языки ассемблера, которые поддерживают синтаксис trailing-h , требуют, чтобы числовые литералы начинались с цифры 0-9, по той же причине, по которой вы говорите, что это будет проблемой в C. DEADBEEFh - это имя символа, AH - это имя регистра x86! Таким образом, ассемблеры поддерживают 0FF00h и / или 0xFF00 , но не FF00h
Peter Cordes 12 март 2018, в 09:20

Показать ещё 4 комментария

15

ПРОСТОЙ

Это префикс, указывающий, что число находится в шестнадцатеричном, а не в некоторой другой базе. Язык программирования C использует его для компиляции.

Пример:

0x6400 переводится на 6*16^3 + 4*16^2 + 0*16^1 +0*16^0 = 25600. Когда компилятор читает 0x6400, он понимает, что число является шестнадцатеричным с помощью термина 0x. Обычно мы можем понять (6400) ₁₆ или (6400) ₈ или что-то еще.

Для Двоичного это будет

0b00000001

Надежда Помогла каким-то образом.

Добрый день,

loyola 05 июнь 2015, в 06:12

1

Двоичные литералы поддерживаются только в C ++, начиная с C ++ 14, и вообще не поддерживаются в C.
Ruslan 25 апр. 2017, в 13:11

0

Предыдущее значение 0 используется для обозначения числа в базе 2, 8 или 16.

По-моему, 0x был выбран для обозначения hex, потому что 'x' звучит как hex.

Просто мое мнение, но я думаю, что это имеет смысл.

Добрый день!

Johnny Low 27 апр. 2017, в 01:59

2

Спасибо за ответ! Я понимаю, что это ваш первый пост в StackOverflow. Ответ мог бы быть более полезным, если бы мнения отличались от фактов.
vivek_ganesan 27 апр. 2017, в 04:57

Ещё вопросы

Теперь я понимаю, что заголовок и текст задают два совершенно разных вопроса. Большинство ответов сосредоточены на вопросе в заголовке. Ответ на вопрос в тексте просто «это ничего не значит - это просто префикс, сообщающий компилятору, что целое число записано в шестнадцатеричном формате».
Чтобы быть педантичным, можно также интерпретировать вопрос в названии двумя различными способами: 1) «Почему шестнадцатеричные числа имеют префикс 0x, а не любой другой префикс или индикатор?» 2) «Почему мы должны использовать префикс при вводе шестнадцатеричных чисел? Конечно, компилятор распознает 58A как шестнадцатеричное число даже без префикса?» Ответ на второе толкование вопроса тривиален. «123» также является шестнадцатеричным числом.
Интересно. Я предполагаю, что они могли использовать начальный 0 и конечный h, чтобы обозначить гекс. Конечный h, вероятно, был бы перепутан с суффиксом спецификатора типа, например, 0xFF00l против 0FF00hl
Этот аргумент подразумевает, что использование начального нуля для обозначения восьмеричных чисел предшествует использованию шестнадцатеричного префикса «0x». Это правда?
Разве они не были изобретены одновременно? Почему когда-либо будет один, а не другой?
AshleysBrain см. Ответ @ Řrřola о том, почему может быть восьмеричное, но не шестнадцатеричное в одно и то же время.
@zdan они использовали это давным-давно. В сборке Intel x86 шестнадцатеричный литерал всегда должен начинаться с 0, если они начинаются с символа. Например, 0xFFAB1234 должно быть записано как 0FFAB1234h . Я помню это из встроенного ассемблера в Паскале, когда я был молодым stackoverflow.com/q/11733731/995714
Языки ассемблера, которые поддерживают синтаксис trailing-h , требуют, чтобы числовые литералы начинались с цифры 0-9, по той же причине, по которой вы говорите, что это будет проблемой в C. DEADBEEFh - это имя символа, AH - это имя регистра x86! Таким образом, ассемблеры поддерживают 0FF00h и / или 0xFF00 , но не FF00h
Двоичные литералы поддерживаются только в C ++, начиная с C ++ 14, и вообще не поддерживаются в C.
Спасибо за ответ! Я понимаю, что это ваш первый пост в StackOverflow. Ответ мог бы быть более полезным, если бы мнения отличались от фактов.

Řrřola · Accepted Answer · 2011-01-03T01-10-00.000Z

Рассказ: 0 сообщает парсеру, что он имеет дело с константой (а не с идентификатором/зарезервированным словом). Что-то еще необходимо для указания базы чисел: x - произвольный выбор.

Длинная история:. В 60-е годы системы с числовым программным номером были десятичными и восьмеричными - мэйнфреймы имели 12, 24 или 36 бит на каждый байт, который делительно делится на 3 = log2 (8).

Язык BCPL использовал синтаксис 8 1234 для восьмеричных чисел. Когда Кен Томпсон создал B из BCPL, вместо этого он использовал префикс 0. Это здорово, потому что

целочисленная константа теперь всегда состоит из одного токена,
анализатор все равно может сразу сказать, что он получил константу,
синтаксический анализатор может сразу указать базу (0 то же самое в обоих базах),
он математически нормальный (00005 == 05) и
не нужны специальные специальные символы (как в #123).

Когда C был создан из B, возникла необходимость в шестнадцатеричных числах (PDP-11 имел 16-битные слова), и все вышеперечисленные пункты были по-прежнему действительны. Поскольку восьмеричные все еще нужны для других машин, 0x был произвольно выбран (00, вероятно, был исключен как неудобный).

С# является потомком C, поэтому он наследует синтаксис.

Я не думаю, что 0x за 00 было предпочтением / неловкостью. 00 сломает существующий код. 0010 как восьмеричное равно 8 , а 0010 как шестнадцатеричное будет 16 . Они не могли использовать любое число в качестве индикатора второй цифры (кроме 8 или 9 , и ни одно из них не имеет никакого значения, связанного с шестнадцатеричной), поэтому буква обязательна. И это оставляет либо 0h или 0x ( H e X idecimal). С этого момента кажется, что он действительно вернулся к предпочтениям.
Похожие страницы : stackoverflow.com/questions/18987911/… и stackoverflow.com/questions/11483216/…
Использование префикса 0 для восьмеричного кода на протяжении многих лет вызывало очень много проблем. Особенно в таких странах, как Великобритания, где номера телефонов начинаются с 0 . Javascript и многие другие языки будут анализировать их как восьмеричные, искажая число перед сохранением. Чтобы добавить к веселью, один популярный продукт базы данных будет молча переключаться обратно на десятичный анализ, если число содержит 8 или 9 .
12, 24 и 36 также делятся на 4, так почему же они не думают о шестнадцатеричном?
@ LưuVĩnhPhúc Вероятно, потому что шестнадцатеричное не очень важно. Большая часть аппаратного, программного обеспечения и документации того времени гораздо лучше соответствуют восьмеричным. BCPL был впервые реализован на 36-битном IBM 7094 с форматом инструкции, разделенным на две 3-битные части и 2 15-битные части; 6 битных символов; и документация в восьмеричном. Ранние реализации B были на PDP-7 (18 бит) и Honeywell GE-945 (36 бит, но с 18-битной адресацией и поддержкой 6 и 9-битных байтов). 16-битный PDP-11 вышел после B, поэтому не сильно повлиял на его дизайн.