Gabriel Dos Reis wrote:
| > 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.
Yes, I had transformatio
Mark Mitchell <[EMAIL PROTECTED]> writes:
| 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/RE
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 f
Mark Mitchell <[EMAIL PROTECTED]> 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 h
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 directi
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.
Jason
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Furthermore, 9.3.1/3 is at odds with 3.9.3/1, which says:
|
|Each type which is a cv-unqualified complete or
|incomplete object type or is void (_basic.types_) has three corre-
|sponding cv-qualified versions of its type: a const-qua
Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
The function type is no more
cv-qualified than any other function type; the only thing that's
cv-qualified is the type pointed to by the first argument.
The standard does not agree with you though, see 9.3.1/3.
It does indeed s
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> The function type is no more
> cv-qualified than any other function type; the only thing that's
> cv-qualified is the type pointed to by the first argument.
The standard does not agree with you though, see 9.3.1/3. In fact, what
happens is that we curren
Nathan Sidwell wrote:
I'm looking at holding the CV qualifiers of a member function on the MEMBER_TYPE
node itself, rather than only on the this pointer argument.
I don't think that's a good idea. The "const" on the member function
really does apply to the type pointed to be the "this" pointe
I'm looking at holding the CV qualifiers of a member function on the MEMBER_TYPE
node itself, rather than only on the this pointer argument.
this brings up a design issue of what TYPE_MAIN_VARIANT should be of a cv
qualified member function. Should it be itself (thereby breaking the invariant
tha
11 matches
Mail list logo
