[PATCH INSTALLED]: delete some const shadow functions

Richard Guenther richard.guenther@gmail.com
Sat Sep 1 21:59:00 GMT 2007

On 01 Sep 2007 16:57:21 -0500, Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
> "Richard Guenther" <richard.guenther@gmail.com> writes:
> | On 9/1/07, Tom Tromey <tromey@redhat.com> wrote:
> | > >>>>> "Kaveh" == Kaveh R GHAZI <ghazi@caip.rutgers.edu> writes:
> | >
> | > Kaveh> Me too, I prefer the const shadow functions.  When we start
> | > Kaveh> using C++ in GCC sources I'll convert these to use function
> | > Kaveh> overloading.
> | >
> | > I love the "when" :-).  This seems like a situation where templates or
> | > const member functions would be appropriate.
> |
> | Heh.  In my local experiment to get the middle-end build with C++ the
> | most interesting problem I face is that C++ enums suck.
> No, they don't.  The particular use we are making of them in the GCC
> source code is just plain obscure hackery.
> If I remember correctly, this hack is where I stopped sometime ago.
> I just could not figure out a way to do this that pleases middle-end
> maintainers [we seemed to have different ideas on enums :-) ]
> |  Or how we
> | use them in GCC...  It's hard to fix this in a way that it builds with both
> | C and C++ and still looks sane.  (Given the extra complication that
> | C++ enums may have less precision than an int)
> It is however very possible.  There are (at least, it used to be last
> time I look at it) only very limited cases where we want an enum to
> act like an integer, and to implicitly convert between enums.  At the
> time, I came to the conclusion that, the implicit conversions being
> relied upon reflected objectionable design decisions.
> I'd be very happy to work with you to find out acceptable solutions.

Well, it's certainly all fixable.  The case that doesn't have a nice
workable C++ counterpart is where we do enum "inheritance" like
for enum c_tree_code which extends enum tree_code and we
happily pass c_tree_codes to tree_code prototyped functions for
example.  Of course not too many functions are affected and the
least intrusive way would be to add overloads for the c_tree_code
variant if we build with C++.  (Or of course, add casts at the places
where there are mismatches)  I just didn't see a nicely designed
way to do this kind of "enum inheritance" ;)


More information about the Gcc-patches mailing list