После всего этого времени я никогда не думал задавать этот вопрос; Я понимаю, что это исходило из С++, но в чем причина:
Почему 0? Почему 0x? Есть ли естественная прогрессия для базы 32?
C, предк С++ и Java, был первоначально разработан Деннисом Ричи на PDP-8 в начале 70-х. Эти машины имели 12-разрядное адресное пространство, поэтому указатели (адреса) были 12 бит в длину и наиболее удобно представлены в коде тремя 4-битными восьмеричными цифрами (первое адресное слово будет 000octal, последнее адресное слово 777octal).
Octal не хорошо отображает 8 бит, поскольку каждая восьмеричная цифра представляет три бита, поэтому в восьмеричной нотации всегда будут избыточные биты. Байт для всех TRUE-бит (1111 1111) равен 377 в восьмеричном, но FF в шестнадцатеричном формате.
Hex проще для большинства людей конвертировать в двоичный файл в их головах и из него, поскольку двоичные числа обычно выражаются в блоках из восьми (потому что размер байта) и восемь - это ровно две шестнадцатеричные цифры, но шестнадцатеричная нотация были неуклюжими и вводящими в заблуждение во времена Денниса (подразумевая возможность обращения к 16 бит). Программисты должны думать в бинарном режиме при работе с оборудованием (для которого каждый бит обычно представляет собой физический провод) и при работе с битовой логикой (для которой каждый бит имеет значение, определенное программистом).
Я полагаю, Деннис добавил префикс 0 как простейшую возможную вариацию для ежедневных десятичных чисел и проще всего для тех ранних парсеров, которые могли бы различать.
Я считаю, что шестнадцатеричная нотация 0x__ была добавлена к C чуть позже. Дерево синтаксического анализа компилятора выделяет 1-9 (первая цифра десятичной константы), 0 (первая [незначительная] цифра восьмеричной константы) и 0x (обозначая шестнадцатеричную константу, которая должна следовать в последующих цифрах) друг от друга значительно больше сложный, чем просто использование ведущего 0 в качестве индикатора для переключения с синтаксического анализа последующих цифр как восьмеричные, а не десятичные.
Почему Деннис разработал этот способ? Современные программисты не понимают, что эти ранние компьютеры часто контролировались переключением инструкций на процессор, физически переключающими переключатели на передней панели ЦП или с перфокартой или бумагой лента; во всех средах, где сохранение нескольких шагов или инструкций представляло экономию значительного ручного труда. Кроме того, память была ограниченной и дорогостоящей, поэтому сохранение даже нескольких инструкций было высоким.
Вкратце: 0 для восьмеричного, потому что он был эффективно разобран и восьмеричный был удобен для пользователей на PDP-8 (по крайней мере для обработки адресов)
0x для hex, вероятно, потому, что это было естественное и обратное совместимое расширение на восьмеричном стандарте префикса и все еще относительно эффективное для синтаксического анализа.
Нулевой префикс для восьмеричного и 0x для hex - с ранних дней Unix.
Причиной появления восьмеричного времени является наличие аппаратного обеспечения с 6-битными байтами, что делает восьмеричным естественный выбор. Каждая восьмеричная цифра представляет 3 бита, поэтому 6-битный байт представляет собой две восьмеричные цифры. То же самое относится к hex, из 8-битных байтов, где шестнадцатеричная цифра - 4 бита, и, следовательно, байт представляет собой две шестнадцатеричные цифры. Использование восьмеричного для 8-битных байтов требует 3 восьмеричных цифры, из которых первые могут иметь только значения 0, 1, 2 и 3 (первая цифра действительно "tetral", а не восьмеричная). Нет причин идти в base32, если кто-то не разрабатывает систему, в которой байты имеют длину в десять бит, поэтому десятибитовый байт может быть представлен как два 5-битных "nybbles".
"Новые" цифры должны были начинаться с цифры, чтобы работать с существующим синтаксисом.
У установленной практики были имена переменных и другие идентификаторы, начиная с буквы (или нескольких других символов, возможно, подчеркивания или знака доллара). Итак, "a", "abc" и "a04" - это все имена. Числа начинались с цифры. Таким образом, "3" и "3e5" являются числами.
Когда вы добавляете новые вещи на язык программирования, вы пытаетесь сделать их вписывающимися в существующий синтаксис, грамматику и семантику, и вы пытаетесь заставить существующий код продолжать работать. Таким образом, вы не захотите изменить синтаксис, чтобы сделать "x34" шестнадцатеричным числом или "o34" восьмеричным числом.
Итак, как вы вставляете восьмеричные цифры в этот синтаксис? Кто-то понял, что, за исключением "0", нет необходимости в цифрах, начинающихся с "0". Никто не должен писать "0123" для 123. Таким образом, мы используем начальный ноль для обозначения восьмеричных цифр.
Как насчет шестнадцатеричных цифр? Вы можете использовать суффикс, так что "34x" означает 34 16. Тем не менее, тогда синтаксический анализатор должен прочитать весь путь до конца цифры, прежде чем он узнает, как интерпретировать цифры (если только он не встречает одну из цифр от "a" до "f", что, конечно, указывает на шестнадцатеричный). "Паркер" "легче" знать, что цифра шестнадцатеричная ранняя. Но вам все равно придется начинать с цифры, и нулевой трюк уже используется, поэтому нам нужно что-то еще. "x" выбрано, и теперь у нас есть "0x" для шестнадцатеричного.
(Выше приведено мое понимание синтаксического анализа и некоторая общая история развития языка, а не знание конкретных решений, сделанных разработчиками компилятора или языковыми комитетами.)
Я не знаю...
0 для 0-октального
0x для, ну, мы уже использовали 0 для обозначения восьмеричного и там x в шестнадцатеричном формате, так что там тоже
как для естественного прогрессирования, наилучшим образом посмотрите на новейшие языки программирования, которые могут прикреплять индексы, такие как
123_27 (интерпретировать _ для обозначения индекса)
и т.д.
?
Марк
Есть ли естественная прогрессия для базы 32?
Это часть того, почему Ada использует форму 16 # для ввода шестнадцатеричных констант, 8 # для восьмеричных, 2 # для двоичных и т.д.
Я бы не стал слишком беспокоиться о том, что нужно искать место для будущего роста. Это не похоже на ОЗУ или адресное пространство, где вам нужно на порядок больше каждого поколения.
Фактически, исследования показали, что восьмеричные и гексагоны - довольно приятное место для читаемых человеком представлений, которые совместимы с бинарными. Если вы идете ниже восьмеричного, оно начинает требовать красноречивого количества цифр для представления больших чисел. Если вы выходите выше гексагона, математические таблицы становятся чрезвычайно большими. Hex на самом деле уже слишком много, но у Octal есть проблема, что он не равномерно вписывается в байты.
Существует стандартная кодировка Base32. Он очень похож на Base64. Но читать это не очень удобно. Hex используется, потому что две шестнадцатеричные цифры могут использоваться для представления 1 8-битного байта. И восьмеричное использовалось прежде всего для более старых систем, которые использовали 12-бит байты. Это сделало для более компактного представления данных по сравнению с отображением необработанных регистров в виде двоичных файлов.
Следует также отметить, что некоторые языки используют o ### для восьмеричных и x ## или h ## для hex, а также для многих других вариантов.
Я думаю, что он 0x действительно пришел для мира UNIX/Linux и был выбран C/С++ и другими языками. Но я не знаю точной причины или истинного происхождения.