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

[David Brown]

Weddington, Eric wrote:
>  
>
> > -----Original Message-----
> > From: 
> > address@hidden 
> > [mailto:address@hidden
> > org] On Behalf Of David Brown
> > Sent: Wednesday, January 16, 2008 3:57 AM
> > To: address@hidden
> > 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