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: <70777@microsoft.UUCP>
Date: 19 Feb 91 18:29:23 GMT
References: <70271@microsoft.UUCP> <1991Feb3.195156.151@cbnewsk.att.com> <70450@microsoft.UUCP> <27B94945.5977@tct.uucp>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 39

In article <27B94945.5977@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
|According to jimad@microsoft.UUCP (Jim ADCOCK):
|>There are already, well documented, well thought out, differences between
|>ANSI-C and C++ in regards to void pointers.  I see no reason to assume then,
|>in this case, that ANSI-C and C++ will be the same.
|
|But can anyone imagine a reasonable implementation on which the
|conversion from |T*| to |void*| cannot be reversed?

Yes, I can imagine such implementations.  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.  A void* might then be considered roughly equivalent
to a char*, or alternativelu a void* might be implemented simply as a mapping 
from a given pointer to a unique value -- it might be almost impossible to 
invert the mapping.

Systems using a Modula3-like approach might have T* be a traced pointer,
converting to a void* makes it untraced, converting back to a traced
pointer doesn't necessarily leave you in a happy state again!  Better to
not allow the inverse conversion then, lest the programmer falsely believe
the program is going to work....

So, I'd like to see the pointer conversions allowed on primitive types
be kept separate from the pointer conversions allowed on "Object" types.
This would not mean that C++ compilers on Un*x-like machines could not
support conversion to/from void* willy-nilly.  It would just mean that
portable code could not rely on such conversions if it is to run someday
on a non-Un*x-like machine.

Again, Rekusive is one example of a non-Un*x-like machine, that is designed
with the intent of supporting "Object Oriented" programming.  If people
read about it, 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.  The Cray and 80x86 machines offer two other "successful"
counter-examples.  Again, I claim that the very-long-array-of-bytes model
of CPU architectures doesn't have much to do with "object oriented programming."
Let's try to keep from being unnecessarily tied to overly-restrictive
CPU models.