Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!uw-beaver!stowe.cs.washington.edu!pauld From: pauld@stowe.cs.washington.edu (Paul Barton-Davis) Newsgroups: comp.lang.c++ Subject: Re: cast of a bound pointer: why ? Message-ID: <1991Jun12.180414.16718@beaver.cs.washington.edu> Date: 12 Jun 91 18:04:14 GMT References: <1991Jun11.191016.9873@beaver.cs.washington.edu> <763@taumet.com> Sender: news@beaver.cs.washington.edu (USENET News System) Organization: Computer Science & Engineering, U. of Washington, Seattle Lines: 85 In article <763@taumet.com> steve@taumet.com (Stephen Clamage) writes: >pauld@cs.washington.edu (Paul Barton-Davis) writes: > >>My understanding of this position is that it really boils down to an >>syntactic nicety: > >> ptr to member function != ptr to function > >>Can anyone explain the necessity for this distinction, and perhaps >>more importantly, can anyone comment on the possibility that it will >>no longer be possible to use this construct ? > >It is not a syntactic nicety, but a fundamental semantic issue. > >A non-static member function requires a "this" pointer, which is >implicitly supplied by the compiler when you call it. That is, given > class C { ... foo(); ... } c; >when you write > c.foo(); >it really means something like this (with artificial syntax): > C::foo(&c); > >If you take the address of C::foo, cast it to an ordinary function >pointer, and call foo via that pointer, no "this" pointer is supplied. > int (*fp)() = (int(*)())C::foo; > fp(); // call C::foo with no "this" pointer >Function C::foo presumably uses "this", and will fail. This is the heart of the matter. C++ assumes that EVERY function *requires* a "this" pointer. If one is using C++ for "systems" programming, there are a number of cases where this is not true. The particular one I'm facing involves the use of a much lower level call (via direct asm macros) to a function whose address is already known. The stack and frame pointers are set up *by the C++ code itself* before calling, and it knows exactly what to pass the function. Although I appreciate the idea behind the "this" pointer, it seems to me that there ought to be a way to access a pointer to a member function as if it were a pointer to a function. The fact that there are supposed to be some conventions for how a member function gets called is a side issue, and can be dealt with by noting that "any use of the pointer is undefined", meaning that the implementor is fully responsible for ensuring compatibility between the calling conventions of a C++ implementation and their use of the pointer. That should not mean that there is no way to obtain the pointer however, and it looks as if this is the plan in some future release. So, let me put these criticisms aside, and ask what a better solution is. The context is a threads package. Each thread, when started, runs a function specified by a member function call to "start": Thread::start (object, function, ...) where function will be invoked with "object" as a sort of "this", and any number of additional arguments can be passed to function. The problem is that a thread is not allowed to actually start itself running, but has to wait until the scheduler gets around to giving it time. Hence, between the time a thread calls start() and the time it actually begins, it is a state of "suspended animation", which it enters AFTER having kept a record of the calling state it should be in when it actually begins. The scheduler uses some asm macros to put together a stack frame, and then gets the thread on the move by an explicit assembly call to the function. This means that it MUST have a pointer to the relevant function, which some future implementation of C++ might make it impossible to obtain. Clearly this is only a problem when the function that a thread is supposed to execute is a member function. However, since this is nearly always the case (this is C++, after all), it represents a real difficulty. Any ideas on how one would do this if it were not possible (as it currently is) to obtain the actual address of a member function ? I have a few ideas myself, but would like to see some others if there are any. -- Paul Barton-Davis Man has survived because he did not know how to realize his wishes. Now that he can realize them, he must either change them, or perish.