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

[David Brown]

Anton Erasmus wrote:
> On 15 Jan 2008 at 20:05, Weddington, Eric wrote:
<snip>
> I have not seen the eeprom.h file, so my comments might be totally inapropriate.
> Wouldn't it be better to use static inline functions in stead of macros ? One 
> gets
> the same advantages of macros, but without many of the dangers of macros.
>
> i.e. In stead of having a macro
>
> #define foo(x)  /* Code here */
>
> have an inline static function in the header file:
>
> static inline void foo(int x)
> {
>   /* Code here */
> }
>
> Because the function is static, no code is generated if it is not used. 

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:

static inline void eeStoreByte(uint16_t address, uint8_t data) { ... }
static inline void eeStoreData(uint16_t address, uint8_t *data,
                                        uint16_t count) { ... }
#define eeStoreObject(address, obj) \
        eeStoreData(address, (uint8_t*) &(obj), sizeof(obj))

The eeStoreObject "function" must be written as a macro to get the 
address-taking and sizeof to work nicely.

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!

mvh.,

David