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
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
