Есть ли минус в объявлении структуры, содержащей один массив, упакованным? - PullRequest
0 голосов
/ 14 февраля 2012

У меня есть класс, который внутренне состоит только из массива, например ::10000

class foo {
public:
    // methods
private:
    int myarray[10];
};

В других местах у меня есть упакованная структура (расширение GCC), которая содержит foo:

struct __attribute__((__packed__)) bar {
    foo x;
};

Но GCC жалуется, что 'foo' не упакован, поэтому бар не упакован. Теперь, если я сделаю foo упакованным, ошибка GCC исчезнет. Я намерен использовать foo в контекстах, отличных от того, что находится внутри упакованных структур, поэтому на данный момент у меня есть две версии foo, Foo и PackedFoo. Однако, поскольку каждый из них содержит только массив, и в AFAIK нет такой вещи, как «распакованный массив» в C ++, есть ли у меня вред, если я просто использую Foo и присваиваю ему упакованный атрибут? Будет ли это как-то замедлять код, который генерирует GCC, когда я использую Foo вне упакованных структур?

1 Ответ

1 голос
/ 14 февраля 2012

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

Аналогично, если у вас есть только foo в bar, то упаковка будет бессмысленной. Я полагаю, вы просто удалили остальное содержимое?

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

Вы не можете смешивать и сопоставлять - вы не можете получить доступ к структуре, упакованной в одном месте, и распакованной в другом. Это просто не сработает.

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

...