garya@Solbourne.COM (Gary Aitken) (05/04/89)
OK, everyone has been real helpful and with a few patches and fixes we've
managed to figure out what g++ and cfront are doing with address of
virtual function references. But the whole problem is even worse than
I originally mentioned...
Consider a function
dispatch(objp,fnp)
which has very little knowledge of its arguments. It knows the following:
objp is a pointer to a C++ object
fnp is a pointer to a member function for objp (possibly virtual)
In particular, dispatch has no knowledge of the base class for objp.
None of the methods/syntax discussed so far will allow dispatch to call
fnp on behalf of objp. The code generated by cfront assumes knowledge
of where the virtual table is located based on the base class type;
the virtual table offset is not in a constant place.
I can see one resolution to this problem:
Have cfront force the virtual table to always be at offset 0, so
(objp->*fnp)()
can be made to always work.
The solution we currently use (mentioned previously) is a mod to cfront
which allows
fnp = &objp->f
to return the actual address of the member function, and use a C call
(*fnp)(objp)
Unfortunately, this won't work in some even more esoteric cases, such as
when the object has a member which is the address of a member function of
itself or another object, and the function involved is virtual. Besides,
the above fix relies on knowledge of the implementation (this is passed by
cfront as 1st arg).
Anybody have other thoughts or answers for something that works today?
This is a major hangup for us, since we have user applications inserting
objects and callback functions in a dispatch table.
--
Gary Aitken
Solbourne Computer Inc. ARPA: garya@Solbourne.COM
Longmont, CO UUCP: ...!{boulder,sun}!stan!garyashopiro@alice.UUCP (Jonathan Shopiro) (05/04/89)
In article <937@garya.Solbourne.COM>, garya@Solbourne.COM (Gary Aitken) writes: > OK, everyone has been real helpful and with a few patches and fixes we've > managed to figure out what g++ and cfront are doing with address of > virtual function references. But the whole problem is even worse than > I originally mentioned... > > Consider a function > > dispatch(objp,fnp) > > which has very little knowledge of its arguments. It knows the following: > > objp is a pointer to a C++ object > fnp is a pointer to a member function for objp (possibly virtual) > > In particular, dispatch has no knowledge of the base class for objp. > None of the methods/syntax discussed so far will allow dispatch to call > fnp on behalf of objp. The code generated by cfront assumes knowledge > of where the virtual table is located based on the base class type; > the virtual table offset is not in a constant place. You understand part of the problem correctly. The other part is that it is fundamental to C++ that every operation is type-safe, either because the compiler can prove it, or because the programmer has asserted it with a cast. There are no type-variables in C++, so there is no way of asserting that fnp points to a member function of the class of whatever objp points to. Thus there is no portable solution in C++ for the problem as you have stated it, and I believe there is no solution at all in AT&T C++ 2.0. The best alternative is to be sure that dispatch knows at least the base class of objp, either by defining a ``universal'' base class, or by overloading dispatch (perhaps parameterizing it). s o r r y a b o u t t h i s -- Jonathan Shopiro AT&T Bell Laboratories, Warren, NJ 07060-0908 research!shopiro (201) 580-4229
mat@mole-end.UUCP (Mark A Terribile) (05/06/89)
> OK, everyone has been real helpful ... we've [figured] out what g++ and > cfront are doing with address of virtual function references. But ... > Consider a function > dispatch(objp,fnp) > which has very little knowledge of its arguments. It knows the following: > objp is a pointer to a C++ object > fnp is a pointer to a member function for objp (possibly virtual) > In particular, dispatch has no knowledge of the base class for objp. > Anybody have other thoughts or answers for something that works today? > This is a major hangup for us, since we have user applications inserting > objects and callback functions in a dispatch table. Not today, but in a few weeks. The proper solution, which will unfortunately affect your users, is to represent the callback operation by a base class and to use Multiple Inheritance. Then your users derive their classes to be called back from the callback class, and use a virtual function derived from that class as the callback function. Like lots of other people, I'm looking forward to MI. -- (This man's opinions are his own.) From mole-end Mark Terribile
garya@Solbourne.COM (Gary Aitken) (05/08/89)
>>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
garya@Solbourne.COM (Gary Aitken) (05/08/89)
> Thus there is no portable solution in C++ > for the problem as you have stated it, and I believe there is no solution > at all in AT&T C++ 2.0. The best alternative is to be sure that dispatch > knows at least the base class of objp, either by defining a ``universal'' > base class, or by overloading dispatch (perhaps parameterizing it). The word we have is that 2.0 will solve the problem by passing a descriptor for virtual functions, instead of an offset into the virtual table. The descriptor contains enough info to find the base class. As described in a previous article, there is no way I can have a "universal" base class without putting constraints on the application program, which I don't want to do. The big benefit of "pointer to function" is precisely that you don't need to know anything about the function; otherwise, it would be just as easy to make a big jump table and pass an index (yeah, I know, in concept, not necessarily so in practice). -- Gary Aitken Solbourne Computer Inc. ARPA: garya@Solbourne.COM Longmont, CO UUCP: ...!{boulder,sun}!stan!garya