This is the mail archive of the gcc@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: MEMBER_TYPE and CV qualifiers


Mark Mitchell <mark@codesourcery.com> writes:

| Jason Merrill wrote:
| > I think that the underlying problem here, as with pointers to data members,
| > comes from using POINTER_TYPE in the first type.  Pointers to members are
| > not pointers, and so using POINTER_TYPE just causes confusion.
| 
| I heartily agree.  PTRMEM_CST was a step in the right direction, on

Agreed.

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

-- Gaby


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