dattatri@metaphor.Metaphor.COM (Dattatri) (11/06/90)
Since ANSI-C allows the following:
int (*funcp)();
/* more code and initialization */
funcp(); /* (*funcp)(); is the old K&R style */
and C++ also allows this syntax, I feel it is odd not to allow the same
generalization for pointer to member functions. See code below.
class Pointer {
public:
int Integer;
Pointer(int a=0) { Integer = a; }
void display() { cout << Integer << '\n' ; }
};
main()
{
void (Pointer::*ptf) ();
ptf = &Pointer::display;
Pointer alpha = 57;
Pointer *beta = new Pointer(48);
(alpha.*ptf)(); // Why not alpha.ptf()
beta->ptf(); // this is also not allowed
(beta->*ptf)(); // this is the language rule
}
The only logical argument would be:
The call to a member function through a pointer to a member function
should be explicit in the syntax such that a call through a
pointer to a function and a call through a pointer to a *member*
function appear different.
Would anyone like to comment.
I will post a summary if enough responses are received.
Kayshav -- dattatri@metaphor.combright@nazgul.UUCP (Walter Bright) (11/10/90)
In article <1743@metaphor.Metaphor.COM> dattatri@metaphor.Metaphor.COM (Dattatri) writes:
/ (alpha.*ptf)(); // Why not alpha.ptf()
/ beta->ptf(); // this is also not allowed
/ (beta->*ptf)(); // this is the language rule
The trouble is that the beta->ptf() is a bit difficult to parse. There's a
lot going on there trying to figure out what the user intended.
It may not seem so on the surface, but in trying to work that into
the parser, I thank Bjarne for those extra parens!
P.S. I always thought the ability to dereference a function pointer by
the shorthand method (no *) was a botch in the language. If you are dead
set about how convenient it is, try:
#define func (*func)
Ah well, all water under the bridge!
P.P.S. I also think the address of func should be written as &func. Seems
clear to me!pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/12/90)
On 9 Nov 90 19:57:37 GMT, bright@nazgul.UUCP (Walter Bright) said:
bright> In article <1743@metaphor.Metaphor.COM>
bright> dattatri@metaphor.Metaphor.COM (Dattatri) writes:
[ ... ptf is function member pointer for the class of beta ... ]
bright> The trouble is that the beta->ptf() is a bit difficult to parse.
bright> There's a lot going on there trying to figure out what the user
bright> intended. It may not seem so on the surface, but in trying to
bright> work that into the parser, I thank Bjarne for those extra
bright> parens!
Now, if only other dreadful syntax ambiguities had been resolved as well...
bright> P.S. I always thought the ability to dereference a function
bright> pointer by the shorthand method (no *) was a botch in the
bright> language. P.P.S. I also think the address of func should be
bright> written as &func. Seems clear to me!
On this I am not so sure. I have resolved the great C array problem in
my mind as follows: an array name is a *constant* of type pointer to
something, plus some decoration that is only seen by sizeof (the
decoration is also seen by operator [] for multidimensional arrays).
Thus, no need to use & before array names. The same could hold for
function names -- a function name is the name of a constant of type
pointer to function. This is in a sense the "Algol 68" view of things.
The alternative is to imagine that a function or array name are of some
mysterious function or array type that is otherwise inexpressible (but
is magically recognized by operator [] and sizeof and operator ()), and
when mentioned they are instantaneously converted to a value of the
appropriate pointer type. This seems to be the more conventionl view.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk