NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/std/cplus/1833

Text File | 1992-12-18 | 5.5 KB | 143 lines

Newsgroups: comp.std.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 17 Dec 1992 21:31:29 GMT
Lines: 130

In article <[e-mail]> [e-mail] (Markku Sakkinen) writes:
>In article <[e-mail]> [e-mail] (Jim Adcock) writes:
>>
>>Agreed, and in general those changes have been practical and well motivated.
>>What you suggest is neither.  On the contrary, you ask to legalize your
>>favorite hacks.
>
>No, it's you who are crying for hacks:  programs that happen to work
>in a certain way because of the peculiarities of a certain compiler.
>Now you think it has been OK to break many "strictly conforming" programs!

    BOTH hacks! OK?

    Jims is a 'hack' because it is machine and compiler and even
memory model dependant. Fine. C was designed to handle that. It was
designed for controlling hardware every bit as much, and maybe moreso,
than general programming.

    Markku's is a hack because linear address machines,
for which pointer comparison makes the most sense, are just
one possible architecture. And one which went out of date
many years ago I thought. Aren't von Neumann machines considered
archaic? Isnt the segmented architecture (I mean real
segments like the 386 not 8086 bank switching) just an extension
of the Harvard architecture? Aren't BOTH of these
going to become obsolete with the advent of
distributed persistent object stores?

>
>You have been pleaded a dozen times to give an example.
>Why don't you present one, so we can get this discussion on more
>rational grounds!

    I presented one.. twice. If you want more,
look at almost every C program ever written
for the PC. Many use mixed pointer types.

    Here's an easy example from Microsoft's older
libraries:

    memcpy(void*d, void*s, int n);

Here d and s are only 16 bits. So they had better both
reside in the Data Segment, or all hell breaks loose.
This version of memcpy assumes this is the case.
If you want 20 bit addresses, use

    far_memcpy(void _far * d, void _far * s, int n);

(Or something similar, Borland's libraries never had this problem).

While this isn't an example where total ordering matters,
perhaps you might begin to see how bad things are for
8086 programmers. And perhaps you can understand that
there are sure to be dependencies on pointers being
ordered the 8086 way in 8086 code. On the 8086,
they can be used just like 16 bit integers, and often are.

    A function

    ptrcmp(void*,void*);

wouldnt work if the ptrs were 16 bits anyhow. The < version
is bound to use that implementation for consistency.
The true library function must be

    ptrcmp(void _far *, void _far *);

>>
>>Wrongo.  Again you confuse language and implementation.  On the contrary,
>>I've written an internal implementation of C++ that does have the means to
>>automatically track down and modify all pointers to an object.  There
>>are other systems that do this kind of thing too.  Such as early versions of
>>Windows.
>
>Maybe, but such a system must be terribly expensive in memory and
>processor time;  and your main motivation seemed to be to save
>a couple of processor cycles.

    Windows was expensive on processor time in order
to conserve memory. It had to run on the 8086, in 640K, and did.
Pointers in Windows (real version) were not allowed, except for transient
periods. It had automatic compaction, including chasing the stack
for stack frames. It dumped read-only segments automatically,
and reloaded them just as automatically when required.

    And the guys that wrote it are now the richest men in
the US because of it. And more people us it than any other
GUI. Dont laugh, Microsoft has NT running on MIPS, Unix beware!

>
>is not portable.  Some people indeed want to write portable software,
>and not only for a 1970s state-of-the-art Deci (one tenth) Operating System.

    Hey, others want to write for Unix, which is not
much of an operating system compared to say OS/2 or NeXT either :-).

>
>I already explained that the issue was not to program in terms of
>memory addresses!
>
    How then does one write an operating system, device
drivers, or any other code that MUST assume pointers are
memory addresses?

    The problem is that pointers should be useful BOTH
as memory addresses, and also as 'object accessors'.
Really, operations like p++ should not be legal on
pointers, but we're stuck with them.

    The real problem is that pointers have a meaning
defined by prior C definitions, and so much code
depends on those definition that its not possible
to change them.

    Now if we could write proper object accessors
efficiently and conveniently, we wouldn't need to use
pointers .. except for machine level access.
So perhaps we need operator.() and/or something else
to be able to do this, because at the moment we
cant emulate pointer behaviour in classes.

    Would it be more profitable to consider
why this is, and what we can do about it?

--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------