On Sat, Mar 28, 2015 at 12:36:31PM -0400, Henry So Jr. wrote:
> I would like to change the #defines for ST_, TR_, NLBA_, etc. into
> enums. This would make debugging easier. However, I have two concerns.
>
> Firstly, it changes the size of the structures (= more memory to compile
> a score) unless I use the GCC __attribute__(packed) extension. Are we
> targetting anything other than GCC? If so, does anyone know of a more
> portable way of making enums smaller, or does that mean we switch to C++
> to give enums a specific underlying type?
Both C++ standard and GNU C extensions support enum bitfields, and you could
use them conditionally.
E.g. if using GCC (or other compiler that supports this), you would use enum
bitfields, otherwise either use full enums and increase size, or use ints
instead.
GCC in itself used to use (before it switched to C++ which always supports
this):
#if defined(__GNUC__) && __GNUC__ >= 2
#define ENUM_BITFIELD(TYPE) __extension__ enum TYPE
#else
#define ENUM_BITFIELD(TYPE) unsigned int
#endif
which is then used as:
enum foobar { ..., F1, F2, F3, ... };
struct bar {
...
ENUM_BITFIELD (foobar) : 7;
...
};
(that is the second option). For supporting either enum bitfields, or
full sized enums, you would need some macro that has the bitfield width
as one of the arguments, and would expand either to that
__extension__ enum TYPE : WIDTH
or
enum TYPE
> My next topic is macros. I find macros difficult to read and there can
> be some surprising side-effects to their use as opposed to functions.
> Is there a reason why macros were chosen for gregorio instead of
> functions for certain things? Speed? Should we consider using the GCC
> __inline__ extension or switching to C++ for function inlining?
Note ISO C99 or C11 has inline support too, so no need to jump to C++ for
that, and most contemporary compilers support at least C99.
Note that the extern inline semantics is different between C99 and the GNU
C89 inline extension.
Jakub
_______________________________________________
Gregorio-devel mailing list
[email protected]
https://mail.gna.org/listinfo/gregorio-devel
