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

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

Re: [avr-libc-dev] Progmem types compatibility


From: David Brown
Subject: Re: [avr-libc-dev] Progmem types compatibility
Date: Tue, 10 Jan 2012 10:47:55 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 10/01/2012 10:31, Georg-Johann Lay wrote:
Joerg Wunsch wrote:
As Jan Waclawek wrote:

I agree that having typedefs for the named address space
implementation might be a good thing.  They should probably start

I am really not sure. There is no read use of such a type, it's just because
some guys are to lazy to type some letters. Moreover in the case of pointers,
you have the difference between pointers, const pointers, pointers to const and
const pointers to const etc. and all for arbitrary number of types and other
qualifiers like volatile, signed or unsigned.


It is exactly this sort of multitude of qualifications that makes typedefs essential. If you want a "const pointer to volatile data", you can do it like this:

typedef volatile uint8_t * const ConstPointerVolatileData;

or you can do this:

typedef volatile uint8_t VolatileData;
typedef VolatileData * PointerVolatileData;
typedef const PointerVolatileData ConstPointerVolatileData;


Personally, I much prefer to build up such types stepwise like this (but obviously with more convenient names). I believe it makes it much clearer what is going on at each stage, and where the different qualifiers actually appear.

This is not about laziness - it is about clarity. If someone reading the code has to stop and think about the type of a variable or typedef to figure out where the qualifiers and pointers go, then that's probably bad coding (IMHO, of course).

If you have a type that will always be used as "const", then put "const" in its typedef. If it will always be in flash, put "flash" in its typedef. If you still have to write "progmem" or "flash" explicitly when defining the variable, that's okay - explicit is good, and error or warning messages help you make sure your code is consistent.

For the matter of clearness I'd discourage such code obfuscation, there is no
real benefit.


I agree with your principle, but I'm not sure I agree with your definition of obfuscation in this case.

with flash_ (rather than prog_) then, to clearly indicate they are
*different*, and need a different usage.

__pgmx semantics will be extended, follow patches to PR49868.





reply via email to

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