Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!stl!concurrent!concurrent.co.uk!asc
From: asc@concurrent.co.uk (Andrew Chittenden,ADT)
Newsgroups: comp.lang.c++
Subject: Re: pointers to member functions
Message-ID: <967@sl10c.concurrent.co.uk>
Date: 11 Jan 90 08:10:47 GMT
Sender: news@concurrent.co.uk
Reply-To: asc@concurrent.co.uk (Andrew Chittenden,ADT)
Organization: Concurrent Computer Corp (ESDG), Slough, U.K.
Lines: 66

Thanks to both Roger Scott and Andrew Koenig for responding to my query.
However, I do have a problem with the answers - see below.

roger@procase.UUCP (Roger Scott) replies:
> In article <950@sl10c.concurrent.co.uk> asc@concurrent.co.uk (Andy Chittenden) writes:
> >...
> >// However, how is one meant to achieve the
> >// above effect under v2 (pass an arbitrary function of a derived class
> >// with matching parameters)?
> 
> 1. Declare any/all such functions to be virtual functions in the base class.
>    This is the "right" way.

I am using these functions as part of an exception handling mechanism.
I've also ideas for using them as part of an event driven scheduler
where each step in a cycle is defined by a function on a class with the
same parameters - it seems a shame that I must define all possible
functions on the base class where the actual functions to be despatched
are on the derived class ( a disc scheduler would be separate from a
terminal scheduler).  There must surely be another way.

> 
> 2. Cast.  Have you ever seen a cast involving a pointer-to-member-function
>    *without* a typedef?  This is the "wrong" way.

Why is this the "wrong" way?  I have tried casting but it does not
work.

Andrew Koenig also replies:

> ....
> Watch this, though.  Every member of class `base' is also a member of
> class `derived.'  Therefore you CAN pass a member of class `base'
> to a function that expects a pointer to a member of class `derived'!
> Example:
> 
> 	void f(int (derived::*)(int));
> 
> 	main()
> 	{
> 		f(derived::fn2);	// OK
> 		f(base::fn1);		// also OK!
> 	}
> 
> This may seem backwards at first, but if you think about it for a while
> you will see that it has to be this way, version 1 to the contrary
> notwithstanding.

I hope you're not seriously suggesting that I declare my typedef for the
derived type - this goes against the paradigm.  I understand that the
above would be valid as every member of base is also a member of
derived.

> 
> This phenomenon is often called `contravariance.'
 
I understand why the v2 compiler complains about my example.  What I was
looking for was a way to use the "feature" that was available in v1.2 of
cfront (see my reply to Roger above).  One way may be to use non-class
based functions - this goes against the general principle of keeping
things object-oriented.

Apologies for the late response to these replies, but we have been
having trouble with our news feed.

Andy Chittenden