I guess the main point it should just work for x86 and certain ARM architecture. Everything else doesn't matter, including efficiency, especially if one side is already implemented in a particular way. Yes, structure packing is compiler-specific. In case of Visual C++ one uses #pragma, but I feel like OP uses gcc in both cases. So here comes the syntax http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Type-Attributes.html#Type-Attrib utes I just learned that ARM is bi-endian and can be set up either way. Haven't ever had to deal with these creatures. And that is what endianness is usually about. If you are unlucky the order of 2 bytes of m_voltageMask may be incorrect, in this case you would receiver char[10] first, reverse it, and have a packed structure defined with the inverse order of members. See also http://linux.die.net/man/3/htons . Mikhail > -----Original Message----- > From: Chris Vine [mailto:chris@xxxxxxxxxxxxxxxxxxxxx] > Sent: Friday, April 08, 2011 7:02 PM > To: Mikhail Titov > Cc: 'Igor Korot'; gtk-list@xxxxxxxxx > Subject: Re: Question about GTK+ and timers > > On Fri, 8 Apr 2011 18:36:41 -0500 > "Mikhail Titov" <mlt@xxxxxx> wrote: > > Just use something like __attribute__ ((__packed__)) for your > > structure and you can always cast back and forth from the pointer to > > your structure to an array of bytes (char*). Just make sure that both > > systems have same ending (little or big) and that members' order is > > correct. Otherwise you'll have to swap data within let's say > > m_voltageMask . > > This attribute is compiler specific. He would also have to be careful > to avoid breaking strict aliasing with his casting, or he could have the > compiler "optimize" away some of his code. It is relatively easy to > avoid that (make sure you start with the type you finish with), but I > am not convinced the OP is necessarily up to speed on how to do it > defensively. > > Because this provides unaligned access (on gcc) it can also be > significantly inefficient on particular architectures. > > Chris > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
