I have decided that unions are not worth it. The memory savings go away unless you have more than four char-sized types (which we don't).
I think I'll leave these multi-purpose fields and their corresponding defines alone. That said, I do think this is a code smell. If this were an OO language, I'd definitely do this polymorphically. While such is possible with C, we'd need a pretty heavy framework (a la gtk) to make it even remotely comprehensible. I think I'm basically done with the enum refactoring in the refactor branch. Regards, Henry On Sunday, 29 March 2015 at 05:19:11 pm -0400, Henry So Jr. wrote: > There are a number of multi-purpose fields in the gregorio data > structures, like liquescentia, additional_infos, and even glyph_type. > > I can understand the need to compress these structures as much as > possible since they make up the linked lists that store the entire > parsed score before transformation to GregorioTeX. > > I was thinking of using unions of enums to handle this, but I'm not sure > it's worth it (i.e., I'm not sure if it will make the code more or less > confusing). Thoughts? > > Of the enum-looking defines, left to do are > > *INITIAL - I think I should leave these alone as they correspond to the > physical value in the gabc file. > > _* - the signs - These are combinable values (though I'm not sure exactly > where they are combined), so I'm inclined to not consider them as an > enum. > > H_* - H_BOTTOM is combinable with the others, so I'm inclined to leave > this alone. > > B_* - This does look line an enum, but it sits within the same field as > pitch. This makes sense to convert if I use union (as above). > > G_* - Same comments as B_*, only for the glyph_type field. > > SP_* - These are characters and I think they might correspond with > GregorioTeX values. If this is the case, I will leave them alone. > > Henry > > _______________________________________________ > Gregorio-devel mailing list > [email protected] > https://mail.gna.org/listinfo/gregorio-devel > _______________________________________________ Gregorio-devel mailing list [email protected] https://mail.gna.org/listinfo/gregorio-devel
