Никогда не заглядывай в пирожок…

[dil]

struct uniqueEPGKey
{
        int sid, onid, tsid;
...
        bool operator==(const uniqueEPGKey &a) const
        {
                return !memcmp( &sid, &a.sid, sizeof(int)*3);
        }

Молодцы, блин. Сэкономили полстрочки кода.

Upd: “м-мать”, — звонко откликнулось эхо.

unsigned int magic=0;
fread( &magic, sizeof(int), 1, f);
if (magic != 0x98765432)
{
        eDebug("[EPGC] epg file has incorrect byte order.. dont read it");
        fclose(f);
        return;
}

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

Comments

[dil.livejournal.com]

это не массив, это три отдельных int'а

в массиве все элементы расположены друг за другом, на расстоянии, равном размеру элемента
это из чего следует? Насколько я помню стандарт C, гарантируется только что при инкрементировании указателя на некоторый тип он будет указывать на следующий элемент массива, а на сколько конкретно он увеличится - не регаламентируется. А это вообще C++.

понадобиться может, например, для ускорения работы в 64-битовом режиме процессора с 32-битовыми int'ами. хотя ситуация гипотетическая, ятакого тоже ни разу не видел, но всё равно не понимаю, зачем раскладывать себе потенциальные грабли. Трудно было явно сравнить три int'а что ли?

[some41.livejournal.com]

> это из чего следует?
из стандарта. по определению
An array type describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type.
С++ в этом месте совместим с С.
ну и вообще, нету другого выбора -- до С99 единственный способ сделать массив динамической длины это malloc(sizeof(T)*n). в С++ есть new T[n], но malloc тоже поддерживается.

> понадобиться может, например, для ускорения работы в 64-битовом режиме процессора с 32-битовыми int'ами.
не верю. даже если предположить, что у нас нет операции загрузки 32-ух битного слова (если есть, то и говорить не о чем), то добавлять один шифт на 32 для нечетных слов будет дешевле, чем переводить кэш и шину загрузку мусора.

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

в общем, как ни криво написано, в реальной жизни очень маленькая вероятность сломаться.

[dil.livejournal.com]

а для чего тогда вообще придумали выравнивание данных по границе слова, если операции загрузки отдельных байтов всё равно всегда были?

[some41.livejournal.com]

каких данных? выравнивать 8-битные данные на 64-бита вроде еще не придумывали.

обычно выравнивают по 2 причинам 1) данные размера N удобно грузить, когда они выравнены на N 2) для лучшего расположения в кэше; в частности, если грузить не выровненные данные, load может пересечь границу cache line, что неприятно.

ни 1) ни 2) выравнивание 32-бит на 64 в структуре не требуют.

[dil.livejournal.com]

впрочем, это всё о массивах. а тут три отдельных int'а, хоть и в составе структуры.

[some41.livejournal.com]

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