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: [PATCH INSTALLED]: delete some const shadow functions


"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.

-- Gaby


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