From -7959124890486369554
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,27b216646bf2abb1
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1991-03-09 07:14:24 PST
Path: gmdzi!unido!mcsun!uunet!spool.mu.edu!news.cs.indiana.edu!msi.umn.edu!cs.umn.edu!ux.acs.umn.edu!vx.acs.umn.edu!dhoyt
From: dhoyt@vx.acs.umn.edu (DAVID HOYT)
Newsgroups: comp.std.c++
Subject: Re: Conversions to/from void*, redux
Keywords: Sun, C++
Message-ID: <3583@ux.acs.umn.edu>
Date: 9 Mar 91 14:09:16 GMT
References: <71031@microsoft.UUCP> <27D5708A.29CF@tct.uucp> <3568@ux.acs.umn.edu> <27D8437B.F13@tct.uucp>
Sender: news@ux.acs.umn.edu
Reply-To: dhoyt@vx.acs.umn.edu
Organization: University of Minnesota, Academic Computing Services
Lines: 64
Posted: Sat Mar  9 08:09:16 1991
News-Software: VAX/VMS VNEWS 1.3-4

In article <27D8437B.F13@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes...
>According to dhoyt@vx.acs.umn.edu:
>>The reason that ANSI made this true (mostly, anyway) is because there
>>existed a huge body of code that depended on this equivalence.
> 
>This statement is patently false, as proven by the next statement,
>which is true:
  You missed my point.  The only reason that you can point to any object
with a char*, and sizeof( char ) == 1, is because K&R didn't have void.

>Point 1: ANSI created |void*| explicitly for the purpose of holding
>any data address whatsoever.  That's why, for example, the first two
>arguments to memcpy() are both of type |void*|.  ANSI C++ cannot
>change this most basic characteristic of |void*| without breaking
>compatibility with many ANSI C programs and large portions of the ANSI
>C library.
  C++ is not C.  C++ breaks many compatibilty rules for Fortran.  So what?
They are different languages, even if they both have a common root in
Von Neumann (sp?).  C++ programs that are written as if the language were
C are pretty much the same as C programs written as if they are Fortran
programs: silly.  Are you using char*'s where void*'s are needed, either
in ANSI C or in C++?  I doubt it.  Then why should anyone care if char*
can not point to any object?  Also it is not quite true that char* can
point to anything; they can not point to functions in ANSI C.  The
char* == void* equivalence in ANSI C is only there because there is a large
body of code that uses char* to point to anything.  Void*'s can also point
to anything.  char* == a, void* == a, void* == char*.  Blech.

>Please describe -- exactly -- how |void*|-|char*| equivalence forces
>machines with word addressing into generating "slow code".
  I suppose you are right here.  I was thinking that void*'s would be
optimised by placing them in 24 bit address registers, if they were known
to point to aligned structures.  There is of course no reason that could not
be couldn't be done for char*'s too.  As you might have guessed, I think
that char*'s should point to chars and void*'s should point to a generic
object.  If that distinction is allowed in the language the cray compiler
writers can say "No char*'s?  Great, everything is aligned.  Don't even
bother to check bits 64:62 for an offset in a word."

>(Of course, on word-addressed machines, a |T*| is typically only one
>word, while a |void*| is larger, to specify the exact byte within the
>addressed word.  But that would always be true, regardless of the
>implementation of |char*|.)
  On Cray's word addressed machines, address registers are 24 or 32 bits.
There is no such thing as a nonaligned address.  By convention the top three
bits are used as the offset of a character within a word.  If something
can be guarenteed to be aligned a pointer can be stored in an address
register, otherwise it must be stored in memory, which is slow, or a data
register, of which there are few.

   I'm just bitter because a bad design feature in the original C language
causes me headaches when I port to Cray's.  No code I write, nor those
whom I respect writes code that uses char*'s when void*'s are needed.  Nor
do they assume sizeof( char[ 1 ] ) == 1 != sizeof( char[ 2 ] ), etc.
This makes it relatively easy to port code to Crays.  But the Cray
compilers still have extra bagage in terms of complexity that is not needed.


>>But what do I know?
> 
>An excellent question.
 Thanks.

  david | dhoyt@vx.acs.umn.edu