Weddington, Eric wrote:
-----Original Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of David Brown
Sent: Wednesday, January 16, 2008 3:57 AM
To: [email protected]
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
In general, I agree with you - static inline functions are often
preferable to macros, and are underused by many people. They
are type
safe, can easily have local variables and multiple statements without
horrible "do {} while (0);" constructs, don't need line continuation
characters, and so on. However, there are other things you
can do with
macros, that can't be done with inline functions. I don't
know what the
new API will look like, but there might be something like this:
It's not a new API, per se, in that the interface remains the same. It's
just a new implementation to fix bugs and problems with the current
implementation.
Anyway, judging from the predominance of static inline
functions (often
with the ((always_inline)) attribute), I reckon that Eric will use
static inlines where possible!
- The way they are written now, the do{...}while(0) construct is not
needed and not used.
- The way they are written now, they have local (to a block level)
variables.
- Who cares if it has line continuation characters or not? The user
won't seem them.
These are just general points - code that is neater and easier to read
is better code, all other things being equal, and "do {} while (0)"
loops and other messy bits of macros make code harder to read.
But in a library, the balance is different from application level code -
here it is well worth using whatever constructs are needed to get the
best generated code. As you say, users won't see them.
- Yes, they are type safe. But the macros ensure that parameters are
typecast to the types needed.
- These types of inline assembly macros are used elsewhere in avr-libc,
notably <avr/pgmspace.h>, <avr/boot.h>, and IIRC <avr/sleep.h>. Do you
propose to change all of this? Do you propose to do the work required?
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.
mvh.,
David
Eric Weddington
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
