This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: (C++) Casting of a local pointer-to-member variable
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Subject: Re: (C++) Casting of a local pointer-to-member variable
- From: Jason Merrill <jason at redhat dot com>
- Date: 02 Mar 2001 16:36:46 +0000
- Cc: Chandra Chavva <cchavva at cygnus dot com>, gcc-patches at gcc dot gnu dot org
- References: <Pine.SOL.3.91.1010228095029.3457B-100000@emperor.cygnus.com><3A9FB4B3.4E0FDC5C@codesourcery.com>
>>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:
> Chandra Chavva wrote:
>> * semantics.c (finish_parenthesized_expr): Call resolve_offset_ref()
>> to give appropriate error message if the qualified_id of a
>> pointer-to-member is enclosed in parenthesis.
> But it's not necessarily an error - we can only determine so when we've some
> context to provide type information.
No, but I think calling resolve_offset_ref is the right thing to do here.
AFAIK, the only purpose of (this use of) OFFSET_REF is to support
generating pointers to members; once that's no longer a possibility, we
don't need the OFFSET_REF anymore. Getting rid of it here means we can
lose PTRMEM_OK_P as well. Yay, simplification.
Actually, my preference would be to do away with (this use of) OFFSET_REF
entirely, and have a special parser rule for & nested-name-specifier
identifier. Life would be simpler yet without resolve_offset_ref.
(Note that OFFSET_REF is also used for .* and ->*, which really ought to
have their own code.)
> I think you'll need to tweek the error message when we determine that we
> would've selected a member function, but can't because of the
> parentheses.
It actually ends up hitting
wa3.C: In function `int main()':
wa3.C:7: assuming pointer to member `void A::f()'
wa3.C:7: (a pointer to member can only be formed with `&A::f')
> Do you have a test case?
struct A {
void f ();
};
int main ()
{
void (A::*p)() = &(A::f);
}
Jason