Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!otc!mikem
From: mikem@otc.oz (Mike Mowbray)
Newsgroups: comp.lang.c++
Subject: Re: cfront/c++ problem
Message-ID: <253@otc.oz>
Date: Fri, 11-Sep-87 01:45:29 EDT
Article-I.D.: otc.253
Posted: Fri Sep 11 01:45:29 1987
Date-Received: Sat, 12-Sep-87 16:08:01 EDT
References: <6191@apple.UUCP>
Organization: OTC Development Unit, Australia
Lines: 43
Keywords: pointer to virtual method
Summary: It's a bug

In article <6191@apple.UUCP>, joemac@apple.UUCP (Joe MacDougald) says:

> struct T {  /* ........ */ };
> 
> int T::getf()  { return f; }
> 
> typedef int (T::*PROC)();	// S 5.4.5  p. 154 : pointer to member fn
> 				// of T taking no args, returning int.
> main()
> {
> 	T t;			// t is an instance of T
> 	PROC p = &T::getf;	// p points to T's member function getf
> 
> /*ERROR*/ int r = (t.*p)();	// call function pointed at by p, assign to r
> }
> 
> Nowhere does Stroustrup mention pointers to virtual methods, so I wonder
> if it is a valid operation.

It is indeed a valid operation. In fact, cfront is quite smart. It will
actually find the right function when dereferenced even though it's virtual
(which is non-trivial if you think about it).

I understand the problem is that the current grammar has problems with the
typedef. If it is simply replaced, things work. E.g:

    int (T::*p)();

    main()
    {
	T  t;
	int r = (t.*p)();
    }

is okay. Trouble is that the declaration of p has to be outside the function,
which is a pain. If it's inside, there's an (incorrect) syntax error. I
understand that the next release will address this bug.

			Mike Mowbray
		    Systems Development
			|||| OTC ||

		    ACSnet:  mikem@otc.oz   UUCP:  {uunet,mcvax}!otc.oz!mikem