From -7986616733910561389 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,1e1d3ed27fda1584 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-04-08 12:33:19 PST Path: gmd.de!xlink.net!fauern!news.th-darmstadt.de!terra.wiwi.uni-frankfurt.de!zeus.rbi.informatik.uni-frankfurt.de!news.dfn.de!scsing.switch.ch!swidir.switch.ch!univ-lyon1.fr!jussieu.fr!math.ohio-state.edu!cs.utexas.edu!not-for-mail From: jamshid@ses.com (Jamshid Afshar) Newsgroups: comp.std.c++ Subject: Re: casting class function addresses Date: 8 Apr 1994 14:33:19 -0500 Organization: SES, Inc., Austin, TX, USA Lines: 71 Sender: daemon@cs.utexas.edu Message-ID: <9404081933.AA22782@ses.com> References: <41768@mindlink.bc.ca> <9404041757.AA28726@ses.com> NNTP-Posting-Host: cs.utexas.edu In article , Roger L. Cauvin wrote: >In article <9404041757.AA28726@ses.com>, jamshid@ses.com (Jamshid Afshar) >wrote: >> You can't just treat the block of memory where a particular object is >> stored like a block of memory containing another type of object (chars >> being an exception). > >You can if the objects are of the same size and alignment. If you can >prove that not all member function pointers have the same size and >alignment (an unlikely implementation even if theoretically possible), then >I will concede that coercion of member function pointers *could* result in >a run-time error in *some* compiler implementations. You either missed or didn't agree with some of the things I wrote in the article to which you responded. Here it is again: JA>[...] Some current C++ compilers can optionally, at the JA>expense of letting ptm casts work, optimize the size of ptms. It's JA>still very uncertain whether ANSI/ISO will allow this optimization [...] Borland has offered this optimization for at least a couple of years (in fact, I seem to remember it being the default option a few versions ago). I believe Microsoft also offers this optimization. Basicly, the pointer to member example implementation in ARM 8.1.2c can be smaller if there's no need to store the `delta' member needed by multiple inheritance. I'm not saying that it's likely that ptms will have different alignment requirements, just that it might end up being legal under ANSI/ISO C++. Besides, my paragraph you quote above was in reference to your code: typedef void (A::*AFP)(); typedef void (B::*BFP)(); // class B unrelated to A void g( AFP a ) { BFP bfp = *(BFP*)&a; // definitely undefined run-time behavior } Alignment requirements aside, nowhere does the ARM imply that this might work. You can't treat a block of memory containing an object like it's a block of memory containing a different type of object. I think there's one exception to this besides chars: the address of an aggregate is guaranteed to be the address of the first member: struct S { int i; } s; int* p = (int*)(void*)&s; // okay: p points to s.i int a[10]; int* q = (int*)(void*)&a; // okay: q points to a[0] Note that the layout of non-aggregate classes is undefined: struct D : public S {}; D d; int* p = (int*)(void*)&d; // bad: (void*)&d is not necessarily equal // to (S*)&d >P.S. I picked up the distinction between casting and coercion from a C >book a while back. I don't remember which book it was, though. While >casting is a relatively safe, built-in means of conversion, coercion is a >conversion achieved by casting the address of an object and dereferencing >it. It's good that you understand that casting is a conversion, not just "reinterprit these bits as a...", but like I wrote earlier, K&R 1 and 2 explicitly use the terms casting and coercion as synonyms. I've never seen them distinguished in any C or C++ books or articles I've read. You're of course free to use whatever language you like, but don't be surprised if others don't understand you. Jamshid Afshar jamshid@ses.com