avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Weddington, Eric
Subject: RE: [avr-libc-dev] [RFC] New eeprom.h
Date: Wed, 16 Jan 2008 09:00:47 -0700

 

> -----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.
- 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?

Eric Weddington




reply via email to

[Prev in Thread] Current Thread [Next in Thread]