🚀 go-pugleaf

In article <27D18D22.1608@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
|[ 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" ...

I disagree -- and for the same reasons.  Operator new and delete are
*special* functions.  Even if specified by the user, there is no 
reason why a compiler couldn't generate two versions of operator new
and delete from the user specification.  For example, take the Cray.
A Cray C++ compiler might want to automatically generate two versions
of new and delete from the user specifications.  One version would assume
"byte" alignment, and the other word alignment.  The compiler would be
smart enough to intuit the right new/delete based on the type of the
object involved.

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

I disagree and counter-claim that it is any programmer who insists on 
doing such pointer hacks who is brain-dead.

|(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.)

I remember, and I still disagree.

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

It is acceptible to me that void* and char* have "the same representation"
[whatever that means -- hopefully the ANSI-C committee were not trying
to specify *implementation* choices] -- as long as C++ then does not
*require* that it be possible to convert from char* to class X*.  In 
which case, both char* and void* might refer to a physical location in
RAM, and both char* and void* might be difficult or impossible to convert
back to a class X*.