Le 28/03/2015 17:36, Henry So Jr. a écrit : > I would like to change the #defines for ST_, TR_, NLBA_, etc. into > enums. This would make debugging easier. However, I have two concerns.
Can you just give a litte example to see if I understood correctly? > Firstly, it changes the size of the structures (= more memory to compile > a score) I don't think it's a problem... > unless I use the GCC __attribute__(packed) extension. Are we > targetting anything other than GCC? It would be good to be able to compile with clang. > 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? I have to admit I don't really like C++, so sticking with C sounds better to me, but I'm ok to consider if there are good arguments. > Secondly, using enums in a structure is considered bad for an ABI > because the size of an enum is implementation dependent as just > described. This is only a problem if gregorio will become a library > that other applications link to. I'm not sure it will become one any time soon, but it would be good to keep this possibility for a graphical user interface (who knows...). > 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? Again, switching to C++ seems overkill, but yes, macros could be avoided. They were here for performance, but I think we could focus more on reliability and maintainability now, Gregorio doesn't have any performance issue, and it seems unlikely to have any in the future. Thank you, -- Elie _______________________________________________ Gregorio-devel mailing list [email protected] https://mail.gna.org/listinfo/gregorio-devel
