Почему упакованные структуры не являются частью языка Си?

10

Каждый компилятор C предлагает возможность «упаковать» структуры C (например __attribute__ ((__packed__)), или #pragma pack()). Теперь мы все знаем, что упаковка необходима, если мы хотим отправлять или хранить данные надежным способом. Это также должно быть требованием с первых дней языка Си.

Поэтому мне интересно, почему упакованные структуры не являются частью спецификации языка Си? Они даже не в C99 или C11, хотя необходимость их наличия известна в течение десятилетий? Чего мне не хватает? Почему это зависит от компилятора?

c

— grasbueschel
источник

2

Они не нужны для написания чистого кода на C.

— user253751

7

Я думаю, это потому, что это зависит от комбинации используемого процессора / компилятора. Это означает, что лучше быть директивой компилятора (как это связано с этим), чем языковым аспектом, потому что как это определить? Единственный способ, которым они могли бы сделать это, с союзом.

Статья Рэймонда дает некоторое представление о том, почему это так: http://www.catb.org/esr/structure-packing/

— Франс Бума
источник

Очень интересная статья. (+1)

— Джорджио

С какой трудностью можно позволить коду сказать: «Мне нужна структура, содержащая 12 байтов; поле X должно вести себя как 32-разрядное целое число, хранящееся как младший порядок в четыре октета со смещением 0; поле Y должно вести себя как 64-разрядное целое число» хранится в байтах октетов с прямым порядком байтов по смещению 4 "? Код для обработки этого на любой платформе не должен быть хуже, чем то, что компиляторы уже должны использовать для битовых полей, и в тех случаях, когда программист задает выравнивание, совпадающее с собственной машиной, может быть гораздо более эффективным. На других машинах это было бы менее эффективно, но все же переносимо.

— суперкат

5

Есть три основных фактора.

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

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

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

— david.pfx
источник

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

— суперкат

@supercat: за что вы спорите (или против)? Я не понимаю

— david.pfx

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

— суперкат

@supercat: битовые поля являются целыми числами и следуют тем же правилам упорядочивания битов, что и целые числа: реализация определена. Члены структуры упорядочены по границам символов, как объявлено, возможно со вставленной упаковкой. Концептуально они совершенно разные. [Вам нужно будет задать другой вопрос, если вы хотите расширить свое предложение, но я не думаю, что оно сработает вообще.]

— david.pfx

0

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

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

— Сору
источник

2

??? Вы ответили на вопрос «Почему не в стандартном языке», сказав «потому что не в стандарте» ...

— Эмилио Гаравалья

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

— grasbueschel

1

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

— Ден04

1

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

— суперкат