Re: [lwip-devel] [bug #35875] #define ⇒ enum?

[David Brown]

On 19/03/2012 14:54, Bill Auerbach wrote:
>> -----Original Message-----
>> On Behalf Of David Brown
>> Sent: Monday, March 19, 2012 8:01 AM
>> Subject: Re: [lwip-devel] [bug #35875] #define ⇒ enum?
>>
>> Using enum types for the values can cause warnings if you use a compiler
>> and warnings that check for mixes between enumerated types and integers,
>> or if you compile in forced C++ mode.  So while using enum types is good
>> in some ways, it may mean extra explicit casts to make the code compile
>> cleanly in all cases.
> 
> Although this is strictly true, in practice any decent compiler will not
> promote a constant to an int if it is used in a way that allows the same
> correct result by not promoting.  A compiler that can generate an 8-bit
> compare of a char to a constant compare probably would do this (and IMO
> isn't very good if it doesn’t).
> 

Yes indeed - and the compiler will do exactly the same with an enum as
with a #define'd value (and in most cases, also with a "static const").
 My point was not that a #define'd value was bad because it is a true
"int", but that it is no different from an enum.

> I think on most compilers changing to enum will make the code size slightly
> larger.  It should improve things in a debugger which (again if good) if it
> will show the enum member name when viewing an enum variable.  I've seen a
> compiler with a compiler option use an 8-bit enum when all of the members
> fit in 8-bits - I don't know if any mainstream compilers do this.

Most embedded compilers will have a way of generating "short" enums,
even though these are technically non-standard.  But when dealing with
constant values for comparisons or assignments to shorter variables
(like an u8_t), the code generated should be as small and fast as with a
#define'd int.

> 
>> An alternative might be to use "static const u8_t" values rather than
>> "#define" macros, but again there could be problems with warning-free
>> compiles if the values are used in several places.
> 
> And a compiler is not prevented by the standard from created storage for
> this IIRC.
> 

True enough - the standards don't prevent the compiler from creating
storage here.  But neither do the standards prevent the compiler from
creating storage for a normal "int" constant (indeed, some compilers
will actually do that - on some 32-bit RISC architectures it is more
efficient to use a "load from memory via a small data pointer plus
16-bit offset" instruction than a "load 16-bit immediate with shift"
then a "or 16-bit immediate" instruction pair).

It is up to the compiler to generate efficient code from the source code.

Having said that, not all compilers are equally good as such code
generation - and support for poor compilers is a good reason for
avoiding "static const" in portable code like this.

> Bill