Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.lang.c++ Subject: Re: cast of a bound pointer: why ? Message-ID: <72979@microsoft.UUCP> Date: 18 Jun 91 18:05:26 GMT References: <1991Jun11.191016.9873@beaver.cs.washington.edu> <763@taumet.com> <1991Jun12.180414.16718@beaver.cs.washington.edu> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 89 In article <1991Jun12.180414.16718@beaver.cs.washington.edu| pauld@stowe.cs.washington.edu (Paul Barton-Davis) writes: |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. Okay, since you've already agreed that "any use of the pointer is undefined" -- then the problem is solved. Just define your "pointer" to be the standard C++ member function pointer, and refuse to call that pointer using standard C++ syntax. Given that you are willing to refuse to use that pointer using standard C++ syntax, you have exactly what you're asking for: namely a pointer whose use is undefined. Note there are some "special" aspects about member function pointers that you need to be aware of: * on many C++ implementations member function pointers are more the 32 bits * its unlikely that any two independently created C++ compilers will use the same internal bit representation for these pointers of more than 32 bits. But then, what can one *do* with these pointers whose use is undefined? Well, one can note that their use is only undefined within the standard C++ language: * One can still use assembly language to do what you want to them. * One can still use "C" to do what you want to them. * One can still use "C++" and unions to do what you want to them. Well, what *can't* one do with these pointers then? * One can't insist that all C++ implementations use the same calling conventions for member functions -- which I think was the whole reason for not requiring a standard conversion in the first place. Rather, compiler implementors are given the freedom to use whatever member function calling conventions are best for their architectures and their customers. [If, for example, member function pointers where defined *in the C++ language* to just be the same as "C" functions with the this pointer passed as the first parameter, then C++ member functions would have to use "C" calling convention -- but many C++ compilers are already using more efficient calling conventions for member functions than this!] Such is the difference between *language* and *implementation*. The C++ *language* needs to give the C++ *implementers* the freedom to write compilers making the best use of present -- and future -- CPU architectures. PS: Okay, lets say one decides to use C++ unions to extract the 32-bit byte address of a member function. One still has to figure out how to correctly set up the call stack [or the appropriate registers in register calling-convention compilers.] Given that some C++ implementations have different C++/member-function calling conventions than C/C-calling- convention functions -- one may still have to use some macros, assembly, or whatever, to complete the job. PPS: Given the difference between language and implementation, there's nothing much to keep your favorite compiler vendor from adding some optional extensions to their implementation [assuming their implementation uses standard "C" calling convention] to do what you originally asked for. They, and their customers, just have to be willing to put up with a little slower code. If that's what you think is best, go lobby your vendor for it! PPPS: Personally, *I* think C++ compiler vendors should aim for the fastest possible code, and should leave out hack "features" that lead to slower code. [cast from const being one such "feature"]