Open tehKaiN opened 2 years ago
Not sure if it helps but I've seen this pattern in some C code in the wild:
typedef uint8_t my_enum_t; enum {
FOO = 1,
BAR = 2
...
}
Basically you don't use the enum in function arguments, you only ever use the properly sized type. C++ lets you define the size which is a lot nicer (as does C23 now).
I would say if not the above pattern, -fshort-enums is the way to go.
Looks cool! The only downside is that intellisense will show FOO as part of anonymous enum and there will be a lost opportunity to put proper values in the first place of suggestion list when typing tMyEnum eValue =
.
I'll probably stick to C23 stuff falling back to this construct using some macro magic to keep the compatibility with Bebbo compiler. Like:
#if OLD_C
#define SIZED_ENUM(name, backingType) typedef backingType name; enum
#else
#define SIZED_ENUM(name, backingType) typedef enum name: backingType
#endif
But I'll have to see how vscode's intellisense behaves with that once C23 ships. On the side note, docs for this one C23 feature are very scarce and are only in this one writeup. I guess the topic is still too fresh. ;)
Currently, most Amiga compilers represent enums as 32-bit ints. GCC compilers have
-fshort-enums
switch, but it comes with a tradeoff:also,
-fshort-enums
is placed on the most not recommended build flags on one of the blog posts I've found: https://interrupt.memfault.com/blog/best-and-worst-gcc-clang-compiler-flags#-fshort-enumsome things to consider:
Still, I have no benchmarks to prove that it doesn't truly affect the performance. One thing to consider is that 68000 has 16-bit data bus and it's always slower to transfer 32-bit data between memory and regs.
Needs more research and benchmarks!