[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 18:01:11 +0100
User-agent: Thunderbird (Windows/20071031)

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



Eric Weddington

reply via email to

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