Re: MEMBER_TYPE and CV qualifiers

[Mark Mitchell <mark at codesourcery dot com>]

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
mark@codesourcery.com
(916) 791-8304