[cfe-dev] Missing lvalue-to-rvalue cast for first arg of ->* ?
Enea Zaffanella
zaffanella at cs.unipr.it
Thu Jun 30 12:17:17 PDT 2011
Il 30/06/2011 19:16, John McCall ha scritto:
> On Jun 30, 2011, at 1:55 AM, Enea Zaffanella wrote:
>> When dumping the AST for the following C++ program:
>>
>> struct B { int mem; };
>>
>> void foo(B* pb, int B::* pmem) {
>> pb->mem;
>> pb->*pmem;
>> }
>>
>> it can be seen that the lvalue pointer pd, when used as the first
>> argument of MemberExpr pb->mem, is subject to an LValueToRValue implicit
>> cast.
>>
>> This is not the case when pb is used as the first argument in the
>> member-pointer operator ->*.
>>
>> Similarly, lvalue member-pointers (such as pmem) occurring as the second
>> argument of ->* and .* operators are not subject to LValueToRValue
>> implicit casts.
>>
>> Is this difference meant (and why)?
>
> No, it isn't. Thanks for pointing it out; fixed in r134170.
>
> John.
>
Thank you for the very quick fix!
I have another question, regarding the AST structure of
CXXPseudoDestructorExpr nodes.
==============
template <class T> class Node {
void bar() { this->~Node<T>(); }
};
template <class T>
void foo(Node<T>* n) { n->~Node<T>(); }
==============
In method bar(), the "destructed type" (i.e., Node<T> after the tilde)
is a TemplateSpecializationTypeLoc (TSTLoc, for short), which is fine.
In function foo(), parameter n is declared to be a TSTLoc,
but the destructed type is a DependentTemplateSpecializationTypeLoc
(DTSTLoc).
I think I have read some comments in the sources telling that this is
quite a dark corner of the standard ... anyway what is surprising to me
is the fact that in foo() we have a DTSTLoc node with *NO* nested name
specifier. I was under the impression that a DTSTLoc should always have
a non-empty NNS.
So, the questions are:
a) is the DTSTLoc in foo() be considered OK?
and, in case the answer to a) is positive,
b) are there other context (different from CXXPseudoDestructorExpr)
where a DTSTLoc can have no NNS at all?
Thanks in advance for clarifications.
Cheers,
Enea.
More information about the cfe-dev
mailing list