This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reorder some tree codes





I do not like this because we lose clarity in the definition of the macros, and
thus we make debugging much harder.


It's not just that, it's that the in_range changes mean that the compiler will break if you move tree codes around in tree.def.

As I've said, I'm concerned about that too -- but I think calling it "just wrong" is too strong. The style of range-checking enumeration constants is very common in lots of code, and I don't see anything wrong with that. What's a little different here is that tree codes are strewn around over lots of places.

The other difference is that we have no explicit markers that make it clear where to insert things without looking at the tree.h in_range checks.



IE we don't have the equivalent of "first_primary_color" and "last_primary_color" in your example below.



 enum color {
   first_primary_color = 0,
   blue = 0,
   red,
   yellow,
   last_primary_color = yellow,
   purple,
   turquoise,
   mauve
 };


If we had enumeration values named approriately and equal to the things he was testing in the range checks (ie we had FIRST_DECL_CODE/LAST_DECL_CODE, and that was what was being tested again), that would be fine by me.


I just don't like that i have to figure out the endpoints of what is being tested by hunting down how the code is actually doing it, instead of it being clear just from tree.def.

I also think that having the endpoints explicitly delineated in tree.def would solve the problem of people reordering the codes without noticing it might break things.

--Dan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]