Re: [avr-gcc-list] calling function pointers via pointers ?

[Anton Erasmus]

On 29 Sep 2005 at 16:20, David Brown wrote:

> 
> ----- Original Message -----
> From: "Vincent Trouilliez" <address@hidden>
> 
> > On Thu, 2005-09-29 at 14:24 +0200, David Brown wrote:
> > > You've picked a chalenge with your complex menu structures, but
> > > you are definitely going about it the right way.  Unconstrained
> > > arrays are
> almost
> > > certainly the most elegant way to deal with the structures - when
> > > you
> figure
> > > them out fully, you'll be glad you stuck by it.  Just take it
> > > slowly, building your structure piece by small, understandable
> > > piece, with carefully-named typedefs.
> >
> > Okay David, I just reworked my code a bit inspired by your comments
> > and declarations example. I am not sure I quite follow the ins and
> > outs of the syntax of typedefs, but the following works fine:
> >
> 
> You are getting very close...
> 
> The syntax for typedefs is pretty close to the syntax for declaring a
> variable - you just have "typedef" first.  When naming types, it is
> not a bad idea to have some sort of naming convention or other way to
> make it obvious what is a type and what is a variable or function.  My
> own habit (from too much Delphi programming, I guess) is to have type
> names start with a capital T for normal types, P for pointer types and
> F for function pointer types (normally I'm not a fan of prefixes for
> names, but I do like "p" on pointers and "f" on functions - and often
> a postfix "s" for arrays).  For commonly-used types, I don't bother -
> I've used "typedef unsigned char byte" for years.
> 
> >
> > typedef struct {
> > char name[21];
> > void (*fp) (uint8_t);
> > }menu_item;
> >
> 
> Change it to:
> 
> typedef void (*FMenuFunc)(uint8_t);
> typedef struct {
>     char name[21];
>     char padding;
>     FMenuFunc fp;
> } menu_item;
> 
> Then I'd have nothing left to complain about (although no doubt others
> will - conventions and styles are a matter of taste, after all).  Note
> the extra "padding" byte - the compiler will add such a byte anyway,
> to get alignments right (the 16-bit function pointer should be aligned
> on a 16-bit boundary).  Compile with the "-Wpadded" flag to see where
> the compiler has added padding to structures.  Note also the space
> after the } to improve legibility, and the indenting (which you may
> have had already, but lost in the email).  I'd call the struct
> "TMenuItem" rather than "menu_item", but that's purely a matter of
> choice.

With the normal WinAVR make file, the "Packed Structs" option are
used, hence no padding will be done. AFAICR even without using this
option, avr-gcc will pack structs in any case, since the AVR is an 8 bit
processor, and aligning data on other than 8 bit boundaries does
not offer any advantage. It is of course still necessary to be aware
that padding might occur. If the same code was compiled on
a PC, padding bytes will be inserted unless the "Pact Structs"
option is used.



[Rest Snipped]

Regards
   Anton Erasmus
-- 
A J Erasmus