Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Comparison functions for qsort() and bsearch()
Keywords: Sun, C++
Message-ID: <70935@microsoft.UUCP>
Date: 27 Feb 91 21:43:09 GMT
References: <70450@microsoft.UUCP> <27B94945.5977@tct.uucp> <70777@microsoft.UUCP> <27C95508.15D0@tct.uucp>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 58

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", since
|they generate or use pointers of type |void*| which subsequently will
|be or previously have been used as "Object" addresses.

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*.  In the 
worse case schenerio, a C++ compiler might actually have to effectively
turn operator new into a template family of functions returning the
correct pointer types.  Or more likely, the compiler might have to generate two
different kinds of operator new -- one that returns a primitive pointer,
and one that returns an "Object" pointer.  But this is all doable, and
in no way violates the language.

|>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 ???

|>...perhaps we can get away from the Un*x-like prejudice that the
|>*only* way one can implement an architecture is as a very long array
|>of bytes.
|
|Please note that I am a long-time user of the '286 in large model, and
|I am quite aware that a successful implementation of C or C++ does not
|require a "very long array of bytes."  That issue, however, has almost
|zero relevance to the convertability of a |void*|.

I disagree.  Somewhat similar to large model, an "object oriented"
CPU might go with a object#:member-inside-object# pointer representation.
Which is somewhat like a segment:offset representation.  A void* might
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.

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.  *Obviously* it doesn't change any "bits"
in the pointer rep.

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 :-]

Thus, I'd like to see C++ be pretty conservative about what kinds of 
type-hacking conforming compilers are *required* to support.  This in 
no way keeps un*x-like machines from supporting a greater variety of
type-hacking, if they so desire.