А для чего явное задание адреса цифрами, да еще и без приведения к указателю?

Я просто хотел показать, как писать/читать структуру в/из eeprom. Ясно, что указатель "куда" в eeprom надо как-то по-приличнее определить, но и что-то напутанное собой представляет.

Это с непривычки. ведь читается вполне ясно.

AVR-овские штучки.

Я не утверждаю, а спрашиваю/интересуюсь. Для данных в EEPROM может и не будет оверхеда, а вот для памяти данных при использовании union некоторый оверхед все же возникает.

Нет там никакого оверхеда. Беда в том, что это непереносимая конструкция. Для записи/чтения это не играет никакой роли - все на одной системе под одним компилятором. Вопрос в том, на кой это надо, если безо всяких union работает.

Вообще все это относится к сериализации данных. Про это много чего понаписано.

Конечно нет. И про ОЗУ тут напрасно беспокоятся. Совершенно нормально, что я переношу из ЕЕПРОМ в ОЗУ все оперативные данные, работаю с ними - а при необходимости прячу снова в ЕЕПРОМ. Вытаскивать 1 байт из ЕЕПРОМ во время обработки данны - это чуднО


Почему? Куда непереносимая? Или просто Вы ее не переносите


Ну, я это использую потому, что при чтении из ЕЕПРОМ и записи туда подсчитываю контрольную сумму. И мне удобно обращаться поэлементно к массиву. Если и при Вашем подходе можно подсчитывать побайтно сумму - то признаю с готовностью, что много лет у меня болталась напрасно усложненная конструкция Спасибо за подсказку!

Например, тут : http://www.cplusplus.com/doc/tutorial/other_data_types/

написано: "The exact alignment and order of the members of a union in memory is platform dependant."

Или здесь: http://www.drdobbs.com/184403890



Вас же, наверное, интересует crc всей структуры? Кто тогда мешает сделать:

Ну я немного погодя додумал, что погорячился.

Кстати говоря, никто не мешает натравить на начало структуры поинтер char *ptr и прогнать его по всем байтам. Зачем там массив явно объявлять?
Более того, к этому поинтеру можно скобочки нарисовать ptr[] и синтаксически будет выглядеть как массив
Правда, засада может быть если там в структуре для выравнивания дырки имеются. Но, как уже говорилось, нас то интересует crc всей структуры и ничего не мешает посчитать его в месте с теми дырками и с ними же и хранить в EEPROM. Ну а вообще структуру сделать packed чтоб без дырок была....

В общем я тоже не вижу смысла в юнионе. Одни минусы от его использования получаются.

Убедили меня По второму пункту. Ибо, что касается приведенных ссылок


...то здесь я же говорил: использую массив только при записи-чтении всей структуры в ЕЕПРОМ. И мне в это время до лампочки, какое там выравнивание и размещение. Согласны?


Ну, так кто ж знал Спасибо, буду знать. Если crc() есть во всех компиляторах, то даже переносимость не ухудшится.

Но все же не могу не отметить, что в моем случае (с учетом вышеобозначенного способа использования союза) удобство предложенного уважаемым товарищем ergeeff способа - только в обращении к элементам структуры без лишнего .u

какая-то белиберда. Откровенно железозависимые вещи, которые просто обязаны скрываться за каким-нить write///read(void *src, void * dst, size_t size) зачем туда union - ваще непонятно. Структура - это да, без нее сложно.