къде и откога union e станало клас!?
union няма нищо общо с класове ... не мога и да си го представя да има - идеята му е да спестява памет и време!
колкото до преносимостта - аз нямам проблеми с нея

Добре де, кажи само откъде заключи, че НЕ ИСКАМ или НЕ МОГА да го разбера? Търсех най-елементарния начин за постигане на целта(между другото, операцията сама по себе си е толкова елементарна, че не без срам попитах, но режимът ми на работа е такъв, че води до чест отказ дори и по най-елементарни математически операции. Но да не коментирам режима си). За мен най-оправданият начин е най-лесният. Затова използвах тази анатемосана операция. Още веднъж благодаря на всички, които се включиха.

GCC интерпретира union като клас и има доста кофти странични ефекти от това. Твоят пример с двата байта ще се компилира като 4 байта, независимо от пакетиране & подравняване. Имаше го документирано това, сега не мога да го изровя... Но повярвай ми, не може да имаш 2-байтов union под GCC.

Не помня точно ситуацията дето ми union-а ми "разваляше" POD-a и дали не беше свързано само с GCC. Беше някаква смесица от struct+enum+union която си бачкаше под С, но под С++ реши че това не може да бъде POD. А това значи, че не можеш да си инициализираш константи от тоя тип чрез списък (фигурни скобки). Всъщност изобщо не може да имаш константи от не-POD класове, винаги се разполагат в рам, независимо че е const...

А то така или иначе изрично навсякъде се препоръчва union да не се ползва, освен ако не е non-POD клас. Логиката е, че union може да прецака тотално пейзажа, защото операциите с него не са TYPESAFE. Примерно функция, която ти връща union от char и int на практика не знаеш какво ти е върнала...

Предполагам е изгъзица на GCC. Порових документацията на Visual C++ нищо такова не намирам. Пък и много често като си правя комуникацията с разни девайси си прехвърлям разни структури от данни,от PC към девайса и обратно,в които винаги присъстват някакви union-и Като си задам коректно подравняването и всичко си работи.
Вярно този стил на комуникация не е подходящ при работа с Big Endian процесори ама като комуникирам с такъв си мисля отделно

това че ти се е сторило ... съвсем не означава че е така !
за свестен компилатор - няма как union да създаде проблем (освен да си чешеш езика!)

Къде отпрашихте, хора? още amdatlon му е дал отговора, ползвай си го със здраве и не го мисли чак толкова на дълбоко - в крайна сметка ако искаш нещо да работи - напиши го по най-прост начин, без извращения. Че знаеш ли го следващия компилатор какъв ще ти го втъкне?

драскаш си

u16 addr;
u8 addr_h, addr_l;

addr_h = ( u8 ) ( addr >> 8 ) ;
addr_l = ( u8 ) ( addr ) ;

и работи на всякъде, а са два реда без ровене по всичките менуали на поредната ревизия гнус.

Ама разправям аз че някои компилатори товарят кода като не се изразяваш точно.

точно изразяване от типа addr_h = ( u8 ) ( addr >> 8 ) ;
при Hi-Tech съм забелязвал да прави буквално каквото си му написал. Тоест да шифтне 16 битовата стойност и да вземе младшия байт
MicroC е още по смотан от Hi-Tech така че ...

Даже и IAR за 8051 без оптимизации го бях хващал в такова извращение преди години като писах за пръв път тестова програмка за едно Cygnal процесорче. Поне там като включиш оптимизацията се компилира както си трябва.
Сега ми стана интересно и комлилирах набързо подобно нещо в най новия IAR za 8051. И без оптимизации компилира коректно.

Не е зле да се хвърля понякога по един поглед в генерирания асемблерски листинг.

Правилото което трябва да спазват нещастните пикоборци е да се изразяват възможно най точно и да не оставят компилатора да твори. Щото не само пиковете са криви ами и развойните им среди. Но нали са се родили да се мъчат. Трябва да се борят за званието Горд Пикоборец. Някак по добре звучи от редови нещастен пикоборец :)

PIC архитектурата не е мислена за ANSI C поради което има доста "отклонения" в компилаторите. Тези отклонения изначало са мислени да оптимизират (например битово ориентираните инструкции на пика), ама доста често водят до изумителни резултати ако човек очаква ANSI C компилация.

Та както каза Кольо, всеки пикоборец трябва да владее асемблера и да проверя творчеството на компилатора, за да няма после изненадани.

На mikroC е достатъчно само това:

Мразим да вършим работата на линкера. Ако проектът има само 5-6 променливи - добре. Ама ако са 5-6 стотин? След толкова хвалби към mikroC мога ли да вярвам, че линкерът няма да пропокрие "моите" декларации? Или че няма да тури там и други променливи? Трябва ли след всеки билд да инспектирам MAP файла ?

В интерес на истината, едва ли някой може да гарантира как ще се държи компилаторът и какви каши може да забърка. Преди година имах много странен проблем, който нямах време да анализирам. При въвеждане на данни в масив през серийния порт, едната от променливите се записваше ВИНАГИ с грешна стойност. Например, ако имаме 15 елемента, елемемтът Element[9] неизменно(100%) беше с грешка в стойността и никога не се получаваше грешка на друго място в приемането. Отстраних проблема абсолютно идиотски, като разделих приемането на две части. Не вярвам да е моя грешка, защото индексите се даваха с цикъл и не виждам нещо, което да различава точно този елемент от останалите.

Виж сега, аз не препоръчвам да се ползва union за щяло и нещяло... Има си много причини за това и проблемът не е само 1 или друг компилатор.

Ако теб те кефи много - ползвай си го със здраве

Че защо? Нали всеки иска колкото се може по-малко генериран код. И не е задължително всички променливи да са на абсолютен адрес. Линкерът естествено, че ще пропусне този адрес. И не го хваля. Просто според мен така трябва да изглежда един съвременен компилатор. Но пък преди човек да почне да плюе по нещо, най-малкото трябва да се запознае с него... или по - точно да се опита да направи нещо от този сорт...

Ако работиш с Пикове се налага Поне докато свикнеш с приумиците на компилаторите.

Цялата "ненормалност" идва от факта, че този процесор няма РАМ в нормалния смисъл на думата, а има регистри. От една страна това го прави много бърз при достъпа до "РАМ"-а. Но от друга обръща представите на всеки нормален програмист с краката нагоре

От тази гледна точка в 90% от софтуера който съм написал за ПИК, масово работя със статични (и/или глобални) променливи, а не със стек (то това няма и стек в нормалния смисъл на думата). :):) Шантаво нали. Ама този процесор е такъв и в това му е чара. Е някой намират този чар за извратено грозен.... ама който не му харесва, да не ги ползва.

Та съвета ми е - ако искате да практикувате качествен чист "С", пиковете са възможно най-лошия избор за платформа. Това е малко като да пишеш на С за палове и галове :):)

Въобще пика си е процесор за хардуеристи. Хората които са учени на истинско програмиране разбираемо изпадат в тих ужас от пиковете

Всъщност като се замисля, към ден днешен незнам да има друго толкова "различно" ядро като пиковското. Всички други - малко или много си приличат. Докато пиковското е тотално по друга писта, съвсем друга идеология.

Всичко това важи за малките пикове де. 24ката и DSPic са опитали да ги "нормализират" ама успеха е минимален. Виж MIPS-а си е тривиален процесор... май.