chip@tct.uucp (Chip Salzenberg) (03/04/91)
[ Since were's talking about What Should Be, followups to comp.std.c++ ] According to jimad@microsoft.UUCP (Jim ADCOCK): >In article <27C95508.15D0@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >|According to jimad@microsoft.UUCP (Jim ADCOCK): >|>If C++ is implemented on top of "object-oriented" architectures, >|>it may well be that pointers to primitive types have a totally >|>different representation that pointers to "Object" types. >| >|This kind of distinction, while conceptually possible, would seem to >|rule out a user's writing "operator new" and "operator delete" ... > >No. A C++ compiler in such a situation can accept definitions of >operator new and operator delete with the void*, but in generating >actual code return the true pointer type -- in actual application, >new returns a pointer to an actual object type, not a void*. Any compiler that is capable of correct behavior in the presence of a user-defined "operator new" member function is in fact capable of converting a |void*| to an |Object*|. (Remember that the actual function "Object::operator new()" is user-written code that does arbitrary pointer things and actually _does_ generate a |void*|.) If that same compiler is unable to support such a cast in normal code, it is Brain Dead and not worth the floppy it's distributed on. (Before disagreeing, remember that I am not asking for any transformation except for |T*|->|void*|->|T*|. In other word, you have to convert back to the exact same type, or all bets are off.) >|>A void* might then be considered roughly equivalent to a char* ... >| >|Exactly equivalent, if compatibility with C libraries matters. > >Since when did C libraries use operator new and delete ??? This point is unrelated to "operator new". As has been mentioned before, ANSI C requires that |void*| and |char*| have the same representation. If a C++ implementation does not conform to this requirement, then compatibility with C libraries is compromised. That may or may not matter to you, of course, but it matters to me. >.. an "object oriented" CPU might go with a object#:member-inside-object# >pointer representation ... A |void*| may represent a conversion of such >a object:member pair into an underlying "hardwired" address of such a >machine's random access memory. Inverting such an address back into >object:member pair might be most prohibitive. Prohibitive, but not impossible. If it were impossible, then user-written "operator new" and "operator delete" wouldn't work. >So, I believe people who support free-wheeling pointer-type hacking have >a Un*x-like processor model in mind. They can't understand why some pointer >-type hacks *ought* to be prohibited -- since such pointer-type hacking is >*obviously* mearly conceptual. That's an unnecessarily pejoritive statement. I know word-addressed machines, for example, in which "sizeof(int*)" and "sizeof(void*)" differ. I know the Cray (from a distance :-)) which has no integer arithmetic. I know about Burroughs/Unisys (?) machines on which function pointers are several words long. I know a little about capability machines. Etc. My point is that the C++ language itself is tied to fairly traditional architectures unless and until user-written "operator new" and "operator delete" member functions are removed or made optional. >Its not *obvious* to me at all that we aren't signing C++ death warrent some >years down the line if "object-oriented" CPUs start catching on [like they >*ought* to :-] I suspect that Smalltalk is a better match for OOCPUs than C++ or Objective C. And no language can live forever, anyway. >Thus, I'd like to see C++ be pretty conservative about what kinds of >type-hacking conforming compilers are *required* to support. Outlaw "operator new" and "operator delete" and you'll get your wish.