Re: [avr-libc-dev] [RFC] New eeprom.h

[Rick Altherr]

Or inline functions defined in a header file.

--------
Rick Altherr
"He said he hadn't had a byte in three days.  I had a short, so I  
split it with him."

On Jan 16, 2008, at 9:41 AM, "Weddington, Eric" <address@hidden 
> wrote:

> > -----Original Message-----
> > From:
> > address@hidden
> > [mailto:address@hidden
> > org] On Behalf Of David Brown
> > Sent: Wednesday, January 16, 2008 10:01 AM
> > To: address@hidden
> > Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> >
> > Weddington, Eric wrote:
> > >
> > No, no - I think you misunderstood my post.  I was responding
> > to Anton's
> > suggestion of using more static inline functions instead of macros by
> > saying that while static inlines have a lot of benefits, sometimes
> > macros are the right choice - and that avrlibc already uses static
> > inlines where it makes sense.
>
> I was giving this some further thought, and static inline functions
> wouldn't work for avr-libc. Avr-libc is a library of object modules.
> Having static inline functions requires a compilation step. Two  
> things:
>
> - The inline portion wouldn't work because we now have object code,  
> and
> the linking stage (AFAIK) doesn't do inlining.
> - One big reason to move away from compiling code to macros, is that  
> we
> do *not* have a true multi-lib (per device) environment with avr-libc.
> We need to be able to have different variants of code for different
> devices (not just per architecture). Right now, the only way for us to
> do this *is* with macros in a header file.
>
> Eric Weddington
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev