Что говорит стандарт

[intro.abstract]/1:

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

C ++ не может определить квалификатор порядка байтов, поскольку в нем нет концепции порядка байтов.

Обсуждение

О разнице между знаками и порядком байтов OP писал

В моем понимании, порядок байтов - это просто вариант того же принципа [(знак)]: другая интерпретация двоичного шаблона, основанная на информации времени компиляции о памяти, в которой он будет храниться.

Я бы сказал, что у подписи есть семантический и репрезентативный аспект ¹. [intro.abstract]/1 подразумевает, что C ++ заботится только о семантике и никогда не обращается к способу представления числа со знаком в памяти ². Фактически, "бит знака" появляется только один раз в спецификации C ++ и относятся к значению, определяемому реализацией.
С другой стороны, порядок байтов имеет только репрезентативный аспект: порядок байтов не имеет значения.

В C ++ 20 отображается std::endian. Он по-прежнему определяется реализацией, но давайте проверим порядок байтов хоста, не полагаясь на старые приемы, основанные на неопределенном поведении.

¹⁾ Семантический аспект: целое число со знаком может представлять значения ниже нуля; репрезентативный аспект: нужно, например, зарезервировать бит для передачи положительного / отрицательного знака.
²⁾ В том же ключе C ++ никогда не описывает, как должно быть представлено число с плавающей запятой, IEEE-754 часто используется, но это выбор, сделанный реализацией, в любом случае предусмотренный стандартом: _ 4_ "Представление значения типов с плавающей запятой определяется реализацией".

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

struct foo {
    little int x;   // little-endian
    big long int y; // big-endian
    short z;        // native endianness
};

Вы можете надеяться, что это точно укажет макет для независимого от архитектуры обмена данными (файл, сеть, что угодно)

Но это не может сработать, потому что некоторые вещи все еще не определены:

• размер типа данных: вам нужно будет использовать little int32_t, big int64_t и int16_t соответственно, если это то, что вы хотите
• заполнение и выравнивание, которые нельзя строго контролировать в пределах языка: используйте #pragma или __attribute__((packed)) или какое-либо другое расширение, специфичное для компилятора
• фактический формат (подпись с дополнением до 1 или 2, макет типа с плавающей запятой, представления ловушек)

В качестве альтернативы вы можете просто отразить порядок байтов некоторого указанного оборудования, но big и little здесь не охватывают все возможности (только два наиболее распространенных).

Таким образом, предложение является неполным (в нем не различаются все разумные механизмы упорядочения байтов), неэффективным (не достигается того, к чему оно стремится) и есть дополнительные недостатки:

• Представление

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

  Аргумент здесь не в том, что ручное преобразование в / из собственного порядка байтов быстрее, а в том, что его явное управление упрощает минимизацию количества ненужных преобразований и гораздо проще рассуждать о том, как код будет вести себя, чем если бы преобразования были неявными.

• Сложность

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

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

// store T with reversed byte order
template <typename T>
class Reversed {
    T val_;
    static T reverse(T); // platform-specific implementation
public:
    explicit Reversed(T t) : val_(reverse(t)) {}
    Reversed(Reversed const &other) : val_(other.val_) {}
    // assignment, move, arithmetic, comparison etc. etc.
    operator T () const { return reverse(val_); }
};

Целые числа (как математическое понятие) имеют понятие положительных и отрицательных чисел. Эта абстрактная концепция знака имеет несколько аппаратных реализаций.

Порядок байтов - это не математическое понятие. Little-endian - это уловка с аппаратной реализацией для повышения производительности арифметических операций с многобайтовыми целыми числами с дополнением до двух на микропроцессоре с 16- или 32-разрядными регистрами и 8-разрядной шиной памяти. Его создание потребовало использования термина big-endian для описания всего остального, что имеет тот же порядок байтов в регистрах и в памяти.

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

PS: Я согласен с тем, что совместимость двоичных данных в сети или в памяти / хранилище является PIA.

Это хороший вопрос, и я часто думал, что что-то подобное будет полезно. Однако вам нужно помнить, что C нацелен на независимость от платформы, а порядок байтов важен только тогда, когда подобная структура преобразуется в некоторую базовую схему памяти. Это преобразование может произойти, когда вы, например, преобразуете буфер uint8_t в int. Хотя модификатор порядка байтов выглядит аккуратно, программисту все же необходимо учитывать другие различия платформ, такие как размеры int, выравнивание и упаковка структуры. Для защитного программирования, когда вы хотите найти контроль степени детализации того, как некоторые переменные или структуры представлены в буфере памяти, лучше всего закодировать явные функции преобразования, а затем позволить оптимизатору компилятора сгенерировать наиболее эффективный код для каждой поддерживаемой платформы.

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

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

Итак, у вас будет что-то вроде

int ip : big 32;

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

Краткий ответ: если нельзя использовать объекты в арифметических выражениях (без перегруженных операторов) с использованием целых чисел, то эти объекты не должны быть целочисленными типами. И нет смысла разрешать сложение и умножение прямого и прямого порядка байтов в одном выражении.

Более длинный ответ:

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

То же самое и с вывесками. Но не в такой степени. Чтобы использовать числа в качестве чисел, необходимо преобразовать языково-семантические обозначения в обозначения, приемлемые для процессора. Чтобы использовать числа в качестве данных (отправлять их по сети или представлять метаданные о данных, отправляемых по сети, например о длине полезной нагрузки), необходимо выполнить преобразование от big-endian к little-endian и обратное.

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

Если бы в языке была семантика для сохранения чисел с прямым порядком байтов, это позволило бы разработчикам выстрелить себе в ногу, заставляя числа с прямым порядком байтов в программе, которая выполняет много арифметических операций. Если бы она была разработана на машине с прямым порядком байтов, такое обеспечение порядка байтов было бы бесполезным. Но при переносе на машину с прямым порядком байтов возникало много неожиданных замедлений. И если бы рассматриваемые переменные использовались как для арифметических операций, так и в качестве сетевых данных, это сделало бы код полностью непереносимым.

Отсутствие этой семантики порядка байтов или принуждение их быть явным образом зависящим от компилятора вынуждает разработчиков пройти мысленный этап представления чисел как «считываемых» или «записываемых» в / из сетевого формата. Это сделало бы код, который преобразует между сетью и порядком байтов хоста в середине арифметических операций, громоздким и менее предпочтительным способом написания для ленивых разработчиков.

А поскольку развитие - это человеческое усилие, делать плохой выбор неудобным - это хорошо (TM).

Изменить: вот пример того, как это может пойти плохо: Предположим, что представлены типы little_endian_int32 и big_endian_int32. Тогда little_endian_int32(7) % big_endian_int32(5) - постоянное выражение. Каков его результат? Преобразовываются ли числа в исходный формат неявно? Если нет, то каков результат? Что еще хуже, какова ценность результата (который в этом случае, вероятно, должен быть одинаковым на всех машинах)?

Опять же, если многобайтовые числа используются как простые данные, то массивы символов также хороши. Даже если они являются «портами» (которые на самом деле являются значениями поиска в таблицах или их хэшах), они представляют собой просто последовательности байтов, а не целочисленные типы (с которыми можно выполнять арифметические операции).

Теперь, если вы ограничите разрешенные арифметические операции над числами с прямым порядком байтов только теми операциями, которые разрешены для типов указателей, тогда у вас может быть лучший случай для предсказуемости. Тогда myPort + 5 действительно имеет смысл, даже если myPort объявлен как что-то вроде little_endian_int16 на машине с прямым порядком байтов. То же самое для lastPortInRange - firstPortInRange + 1. Если арифметика работает так же, как для типов указателей, тогда это будет делать то, что вы ожидаете, но firstPort * 10000 будет незаконным.

Затем, конечно, вы вступаете в спор о том, оправдано ли раздувание функции какой-либо возможной выгодой.

С точки зрения прагматичного программиста, ищущего Stack Overflow, стоит отметить, что на дух этого вопроса можно ответить с помощью служебной библиотеки. У Boost есть такая библиотека:

http://www.boost.org/doc/libs/1_65_1/libs/endian/doc/index.html.

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

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

Может быть, вы могли бы предложить это комитету. Я не думаю, что это сложно реализовать в компиляторе: компиляторы уже предлагают фундаментальные типы, которые не являются фундаментальными типами для целевой машины.

Разработкой C ++ занимаются все программисты на C ++.

@Schimmel. Не слушайте людей, оправдывающих статус-кво! Все приведенные аргументы в оправдание этого отсутствия более чем непрочны. Студент-логик может найти их несогласованность, ничего не зная о компьютерных науках. Просто предложите это и не обращайте внимания на патологических консерваторов. (Совет: предлагайте новые типы, а не квалификатор, потому что ключевые слова unsigned и signed считаются ошибками).