Gabriel Dos Reis wrote:
| the object-representation side; we need a PTRMEM_TYPE on the type side
| as well. Because we don't have a proper lowering phase, the
| difficulty is that we need to transmute PTRMEM_TYPE into
| OFFSET_TYPE/RECORD_TYPE at some point.
|
| However, that's no excuse for forming a POINTER_TYPE pointing to a
| METHOD_TYPE or member FUNCTION_TYPE. Such things should be replaced
| with the RECORD_TYPEs we presently use to represent pointers to member
| functions.
Hmm, using RECORD_TYPE for both classes and pointer to member
functions seem to me to be less desirable as say, using tree for just
about any data structure. I would think as we gradually move toward
representations closer to the standard specification we would represent
distinct notions by distinct data structures.
Isn't that exactly what I just said above?
> I recon that such
representation needs a lowering stage, but it looks like we're doing
that more or less already. Do I miss something?
Yes -- we don't really have a lowering stage, unless you count
transformation to GENERIC. Doing proper lowering would means lots of
changes throughout the front end. For example, "(a.*b)()" gets turned
into various manipulations of low-level as soon as it is processed.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
