RE: Question about GTK+ and timers

["Mikhail Titov" <mlt gmx us>]

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 cvine freeserve co uk]
> Sent: Friday, April 08, 2011 7:02 PM
> To: Mikhail Titov
> Cc: 'Igor Korot'; gtk-list gnome org
> Subject: Re: Question about GTK+ and timers
> 
> On Fri, 8 Apr 2011 18:36:41 -0500
> "Mikhail Titov" <mlt gmx us> 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
>