This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH to read-rtl.c
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 09 Jun 2005 11:40:04 -0700
- Subject: Re: PATCH to read-rtl.c
- References: <m3ekbbsapy.fsf@uniton.integrable-solutions.net>
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> read-rtl.c implements polymorphism here through the use of the
> underlying integer type of enum rtx_code and enum machine_mode, which
> it assumes to be int or unsigned depending on the circumstances.
> Doing so, allows it to define only one kind of structure (macro_group)
> that contains pointer to various functions (to mimic virtual
> functions). In C++ speak, the game would be that of a class template
> with virtual functions -- though I'm no sure I would actually use
> virtual functios :-).
I'm not enthused about your solution to this problem. My first
reaction was to say that we should get out of the fake polymorphism
game; there ought to be separate data structures for the mode and code
macros. However, the naive way to do that would require duplicating
lots of code. I would like you to investigate further and see if
there is a clever way to make all the types explicit without
duplicating code.
Failing that, I think it would be better to just use inline casts.
There is no readability gain from
#define to_machine_mode(X) ((enum machine_mode) X)
in fact, because one has to go look up the macro definition, it hurts
comprehension.
zw