#прагма ефект упаковки

Мені було цікаво, чи може хтось пояснити мені, що #pragma packробить оператор препроцесора, і що ще важливіше, чому хтось хоче його використовувати?

Я перевірив сторінку MSDN , яка запропонувала деяке розуміння, але я сподівався почути більше від людей із досвідом. Я бачив це в коді раніше, хоча, здається, більше не можу знайти.

#pragma packдоручає компілятору упакувати членів структури з певним вирівнюванням. Більшість компіляторів, коли ви оголошуєте структуру, буде вставляти прокладки між членами, щоб забезпечити їх вирівнювання за відповідними адресами в пам'яті (як правило, кратними розмірами типу). Це дозволяє уникнути штрафу за ефективність (або відверту помилку) для деяких архітектур, пов'язаних з доступом до змінних, які не вирівняні належним чином. Наприклад, дано 4-байтні цілі числа та таку структуру:

struct Test
{
   char AA;
   int BB;
   char CC;
};

Компілятор міг вирішити викласти структуру в пам'ять так:

|   1   |   2   |   3   |   4   |  

| AA(1) | pad.................. |
| BB(1) | BB(2) | BB(3) | BB(4) | 
| CC(1) | pad.................. |

і sizeof(Test)було б 4 × 3 = 12, хоча воно містить лише 6 байт даних. Найбільш поширений випадок використання для #pragma(наскільки мені відомо) - це при роботі з апаратними пристроями, де потрібно переконатися, що компілятор не вставляє прокладки в дані, і кожен член слідує за попереднім. З #pragma pack(1), структура вище буде викладена так:

|   1   |

| AA(1) |
| BB(1) |
| BB(2) |
| BB(3) |
| BB(4) |
| CC(1) |

І sizeof(Test)було б 1 × 6 = 6.

З #pragma pack(2), структура вище буде викладена так:

|   1   |   2   | 

| AA(1) | pad.. |
| BB(1) | BB(2) |
| BB(3) | BB(4) |
| CC(1) | pad.. |

І sizeof(Test)було б 2 × 4 = 8.

Порядок змінних у структурі також важливий. Зі змінними, упорядкованими, як:

struct Test
{
   char AA;
   char CC;
   int BB;
};

і з #pragma pack(2), структура буде викладена так:

|   1   |   2   | 

| AA(1) | CC(1) |
| BB(1) | BB(2) |
| BB(3) | BB(4) |

і sizeOf(Test)було б 3 × 2 = 6.

#pragmaвикористовується для надсилання не портативних (як у цьому компіляторі) повідомлень компілятору. Такі речі, як відключення певних попереджень та пакувальних конструкцій, є загальними причинами. Вимкнення конкретних попереджень особливо корисно, якщо ви компілюєте з попередженнями, коли увімкнено прапор помилок.

#pragma packконкретно використовується для вказівки, що упакована структура не повинна мати своїх членів. Це корисно, коли у вас є інтерфейс, відображений на пам'яті, на апаратне забезпечення, і вам потрібно мати можливість точно контролювати, куди вказують різні члени структури. Це, зокрема, не є хорошою оптимізацією швидкості, оскільки більшість машин набагато швидше справляється з узгодженими даними.

Він повідомляє компілятору межу для вирівнювання об'єктів у структурі. Наприклад, якщо у мене є щось на кшталт:

struct foo { 
    char a;
    int b;
};

З типовою 32-розрядною машиною, як правило, "ви хочете" мати 3 байти прокладки між ними, aі bтак bвийде на 4-байтну межу, щоб максимізувати швидкість доступу (і саме це зазвичай відбувається за замовчуванням).

Якщо ж вам доведеться відповідати зовнішньо визначеній структурі, ви хочете переконатися, що компілятор викладає вашу структуру точно відповідно до цього зовнішнього визначення. У цьому випадку ви можете дати компілятору #pragma pack(1)сказати, щоб він не вставляв прокладки між членами - якщо визначення структури включає в себе прокладку між членами, ви вставляєте її явно (наприклад, зазвичай з членами з ім'ям unusedNабо ignoreN, або щось на цьому наказ).

Елементи даних (наприклад, члени класів і структур), як правило, вирівнюються за межами WORD або DWORD для процесорів поточного покоління з метою покращення часу доступу. Для отримання DWORD за адресою, не розділеною на 4, потрібно щонайменше один додатковий цикл процесора на 32-бітовому процесорі. Отже, якщо у вас є, наприклад, три члени char a, b, c;, вони фактично мають 6 або 12 байт.

#pragmaдозволяє переосмислити це для досягнення більш ефективного використання простору за рахунок швидкості доступу або для узгодженості збережених даних між різними цілями компілятора. Мені було дуже цікаво з цим переходом з 16-бітного на 32-бітовий код; Я думаю, що перенесення 64-бітного коду призведе до тих же видів головних болів для деяких кодів.

Компілятор може вирівняти членів у структурах для досягнення максимальної продуктивності на певній платформі. #pragma packДиректива дозволяє контролювати це вирівнювання. Зазвичай ви повинні залишити його за замовчуванням для досягнення оптимальної продуктивності. Якщо вам потрібно передати структуру віддаленій машині, ви зазвичай використовуєте #pragma pack 1для виключення небажаного вирівнювання.

Компілятор може розміщувати членів структури на конкретних межах байтів з міркувань продуктивності для певної архітектури. Це може залишити невикористані прокладки між членами. Упаковка структури змушує членів бути суміжними.

Це може бути важливо, наприклад, якщо вам потрібна структура, щоб відповідати певному файлу або формату зв'язку, де потрібні вам дані, щоб вони знаходилися на певних позиціях в межах послідовності. Однак таке використання не стосується проблем, пов'язаних з ендіасності, тому, хоч і використовується, воно може бути не портативним.

Він може також точно накладати внутрішню структуру регістру деяких пристроїв вводу / виводу, таких як UART або USB-контролер, наприклад, для того, щоб доступ до регістру здійснювався через структуру, а не прямі адреси.

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

Однак це виглядає як досить тупий інструмент для досягнення цієї мети. Кращим підходом було б кодування міні-драйвера в асемблері та надання йому інтерфейсу для виклику С, а не спіткання з цією прагмою.

Раніше я використовував його в коді, хоча тільки для інтерфейсу зі застарілим кодом. Це була програма Mac OS X Cocoa, якій потрібно було завантажити файли переваг з більш ранньої версії Carbon (яка сама була зворотно сумісною з оригінальною версією системи M68k System 6.5 ... ви розумієте). Файли уподобань в оригінальній версії були двійковим дампами конфігураційної структури, які використовували #pragma pack(1)для уникнення зайвого місця та економії мотлоху (тобто байтів, що в іншому випадку будуть у структурі).

Оригінальні автори коду також використовували #pragma pack(1)для зберігання структур, які використовувались як повідомлення у міжпроцесовій комунікації. Я думаю, що причина тут полягала в тому, щоб уникнути можливості невідомих або змінених розмірів прокладки, оскільки код іноді розглядав певну частину структури повідомлення, підраховуючи кількість байтів з початку (ewww).

Я бачив, як люди використовують його, щоб переконатися, що структура займає цілий рядок кешу, щоб запобігти обміну помилками у багатопотоковому контексті. Якщо у вас буде велика кількість об'єктів, які за замовчуванням будуть розфасовані, це може зберегти пам'ять та покращити продуктивність кешу, щоб упакувати їх більш щільно, хоча нестандартний доступ до пам'яті зазвичай сповільнює роботу, тому може виникнути зворотний бік.

Зауважте, що існують інші способи досягнення послідовності даних, які пропонує #pragma pack (наприклад, деякі користувачі використовують #pragma pack (1) для структур, які слід надсилати через мережу). Наприклад, див. Наступний код та його наступний вихід:

#include <stdio.h>

struct a {
    char one;
    char two[2];
    char eight[8];
    char four[4];
};

struct b { 
    char one;
    short two;
    long int eight;
    int four;
};

int main(int argc, char** argv) {
    struct a twoa[2] = {}; 
    struct b twob[2] = {}; 
    printf("sizeof(struct a): %i, sizeof(struct b): %i\n", sizeof(struct a), sizeof(struct b));
    printf("sizeof(twoa): %i, sizeof(twob): %i\n", sizeof(twoa), sizeof(twob));
}

Вихід такий: sizeof (struct a): 15, sizeof (struct b): 24 sizeof (twoa): 30, sizeof (twob): 48

Зверніть увагу на те, як розмір struct a є саме таким, яким є кількість байтів, але в структурі b додано доповнення (див. Це для деталей прокладки). Роблячи це, на відміну від пакету #pragma, ви можете контролювати перетворення "дротяного формату" у відповідні типи. Наприклад, "char two [2]" в "short int" et cetera.

Чому хочеться ним користуватися?

Для зменшення пам'яті структури

Чому не слід його використовувати?

1. Це може призвести до покарання продуктивності, оскільки деякі системи краще працюють на узгоджених даних
2. Деяка машина не зможе прочитати нестандартні дані
3. Код не є портативним