Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!boulder!stan!garya
From: garya@Solbourne.COM (Gary Aitken)
Newsgroups: comp.lang.c++
Subject: Re: ptr to member function, even worse
Message-ID: <1014@garya.Solbourne.COM>
Date: 8 May 89 14:41:33 GMT
Organization: Solbourne Computer Inc., Longmont, Co.
Lines: 75

>>Have cfront force the virtual table to always be at offset 0, so
>>
>>	(objp->*fnp)()
>>
>>can be made to always work.

>Can't do that - consider this:
>
>    struct s {
>	int s1;
>	char s2;
>    };
>
>    struct t : public s {
>	virtual void f();
>	// ...
>    };
>
>The vptr for class t can't be at offset 0 - s::s1 is already there!

I disagree.  The class record could, by definition, always have a virtual
table pointer allocated at offset zero.  If the class has no virtual
functions, you'd waste a little memory, but it would be a trivial amount,
since it is in the class record, not in the instance record.

> Are you aware that in 1.x
> C++
>     C::MF
> is *not* the same as
>     &C::MF
> ?  The first gives you a non-virtual pointer to C::MF, the second gives you
> a virtual pointer to MF

Hmmm.  In numerous instances of this problem, we are in a base class
member function, and need the address of the virtual member function for
the particular instance record being dealt with.  If I use C::MF from 
within base class C, I will get the address of the base class function,
not the virtual function for the particular subclass.  What I want is
this::MF.

> I still don't really understand what you are trying to do here - could you
> elaborate somewhat?

OK.  We have a fairly complete X window system toolkit based on C++.  X is
essentially an event driven system.  You do a bunch of stuff, then 
periodically poll for asynchronous events requiring the program to do things
like fill in (repaint) the contents of windows.  When you get one of
these events, you know essentially one thing, the window id.  So you need
to build some sort of dispatch mechanism which involves a table lookup on
the window id to get a pointer to a function to call to handle the event,
and an object to call the function on behalf of.  Some of the functions
are internal toolkit functions for the various objects, such as "paint the
text" for a text object.  For these functions, one could have them all
derived from the same base class, which in fact they are.  However, there
is a much larger class of functions which are based on the application
program's objects, of which the toolkit has no knowledge and to which we
would not like to add any constraints.  For example, when a user clicks on
a button in a menu, we wish to call a user definable function.

If you have a relatively simple program with static display objects, your
code looks something like this:

	Set up all the objects.
		This includes getting window id's and telling the
		dispatcher what functions to call when various events
		occur for the windows.
	Do forever:
		Get an event.
		Lookup the function to call and object to use for the event.
		Call the function on behalf of the object.
-- 
Gary Aitken

Solbourne Computer Inc.    ARPA: garya@Solbourne.COM
Longmont, CO               UUCP: ...!{boulder,sun}!stan!garya