From -1490107531513017442
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,e94695845965b249
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-10-21 08:40:08 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Zero-length structures and pointer comparisons
Message-ID: <1992Oct21.154950.14921@ucc.su.OZ.AU>
Sender: news@ucc.su.OZ.AU
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <1992Oct19.055511.18826@jyu.fi> <1992Oct19.152004.8350@lth.se> <7724@charon.cwi.nl>
Date: Wed, 21 Oct 1992 15:49:50 GMT
Lines: 58

In article <7724@charon.cwi.nl> niels@cwi.nl (Niels Ferguson) writes:
>dag@control.lth.se (Dag Bruck) writes:
>
>...
>>A strong ordering of pointers makes much sense in many data
>>structures, even if the ordering of the object values is not well
>>defined.  I believe the most common data type in trees, hash tables,
>>etc. is indeed "pointer to T".
>
>>The ordering of pointers may be implementation defined, and I don't
>>even think it would have to be equal between runs of the same program.
>
>C only defines pointer comparison if the pointers point to objects in
>the _same_array_. The ordering between two pointers that do not point in
>the same array is undefined. That means you cannot rely on any
>property. For example, it might lead to a run-time error, and if it
>doesn't, the ordering of two pointers might change _during_ the run of
>the program. On a segmented machine, an implementation could implement
>pointer comparison based on the actual address. If two segments are
>swapped out and reloaded, their order might change. Any pointers
>within the same segment would still retain their ordering, but the
>order between two pointers in different segments could change at any
>time. I have seen a lot of C programs that would fail on a machine
>like this.

	I dont think this can happen. The LINEAR address changes
but the linear addresses are not what is being compared. At least
on the 486 comparison of segmented addresses will always give
the same results, irrespective of the linear or virtual
addresses they map to. If this were not the case programs
could not store pointers and expect them to remain valid.
>
>C++ didn't try to change the pointer/array structure of C which, if I
>recall rightly, was called 'fatally flawed'. IMHO the unrestricted
>pointer juggling is one of the weakest points of C (and C++), but
>given C, it would be nearly impossible to correct this in C++.

	Its not impossible surely. For example, we could have
a declaration

	int array[6] x;

meaning a REAL array of 6 ints. With bounds checking and
restrictions on pointers. For example if we allowed

	int array[6]* p;
	p++;

the p++ could be checked. Given that this sort of thing
can be done (albiet clumbsily) with templates the question is whether
it is really a good idea to add a proper array mechanism
in addition to the C-array mechanism we already have.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------