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" <[EMAIL PROTECTED]
> wrote:
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Wednesday, January 16, 2008 10:01 AM
To: [email protected]
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
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
