typedef'ing массив против использования структуры в C ++ - PullRequest
Новая
       33

typedef'ing массив против использования структуры в C ++

5 голосов
/ 13 сентября 2009

Нашел интересное использование typedef, в котором я действительно не видел необходимости. 

typedef int Color[3];

Итак, использование будет: 

Color pants;
pants[0] = 0;
etc.

Использование typedef через ptrs создавало странно выглядящий код, который не был ясен.

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

struct Color {
int r;
int g;
int b;
};

Color pants;
pants.r = 0;
etc.

Вы можете использовать объединение, чтобы выразить переменные в виде массива или по отдельности, что является странным, но все же ясно, что оно несколько сложнее, чем одно значение.

Может ли кто-нибудь дать представление о достоинствах использования массива typedef против структуры?

Ответы [ 6 ]

8 голосов
/ 13 сентября 2009

Возможно, структура была выровнена не так, как хотел оригинальный кодер. возможно, он был дополнен до 16 или 32 бит. Создание массива гарантирует отсутствие заполнения структуры. Это было передано в драйвер или на какое-либо аппаратное устройство?

7 голосов
/ 13 сентября 2009

Использование простого массива - плохая идея по нескольким причинам.

  • Тип int[] затухает до int * при использовании в списке параметров.
  • Вы не можете использовать operator= для назначения массивов.

Либо struct, либо boost::array послужит цели гораздо лучше.

5 голосов
/ 13 сентября 2009

Еще одно преимущество формы struct : если вам когда-либо понадобится передать цвет в функцию, а затем принять его размер: 

void foo (Color c)
{
    size_t s = sizeof(c);
}

Если вы используете форму массива, c будет интерпретироваться как Color * (массивы передаются через указатель на их первый элемент), а sizeof(c) будет равно sizeof(int*). Был там, сделал это, был укушен там.

Редактировать: форма структуры будет вести себя (наивно) ожидаемо.

3 голосов
/ 13 сентября 2009

Вы хотите, чтобы выражение массива могло иметь цикл.

Таким образом, если у вас должны формы [rgb], вы используете объединение, но это увеличивает количество набираемых текстов.

:: Вздох ::

2 голосов
/ 13 сентября 2009

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

Что касается того, лучше ли .x или [], вы можете перегрузить operator[] для структуры (используя переключатель в этом случае). Любой приличный компилятор оптимизирует это, чтобы быть эквивалентным static_cast<int*>(this)[index], так что нет потери производительности Вы можете, конечно, пойти с профсоюзом, но это не очень помогает. Другой возможностью является реализация .x () и т. Д. В терминах [].

В любом случае, я бы порекомендовал использовать структуру, так как вы ничего не теряете (вы все равно можете преобразовать массив из Color в int*, но вы можете писать алгоритмы проще, когда берете структуру, чем при int* - например, если вам нужна яркость, в IMAO проще иметь красивую функцию-член / функцию, принимающую Color вместо int *, потому что с int вы никогда не сможете быть уверены, что это RGB, RGBA, YoCoCg, пока с цветом, вы можете применить это.

И последнее, но не менее важное: структура дает вам возможность инициализировать все члены в допустимые значения / sane / debug, если это необходимо.

0 голосов
/ 13 сентября 2009

Я думаю, что массив использовался как кортеж, поэтому boost :: tuple можно рассматривать как альтернативу, которая лучше показывает намерение.

...