[Top][All Lists]

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

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

From: David Brown
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Date: Wed, 16 Jan 2008 11:57:22 +0100
User-agent: Thunderbird (Windows/20071031)

Anton Erasmus wrote:
On 15 Jan 2008 at 20:05, Weddington, Eric wrote:

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 
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!



reply via email to

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