NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/std/cplus/1902

Text File | 1992-12-23 | 5.0 KB | 151 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: 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]>
Date: Wed, 23 Dec 1992 17:27:35 GMT
Lines: 138

In article <[e-mail]> [e-mail] (Johan Bengtsson) writes:
>John MAX Skaller ([e-mail]) wrote:
>
>:   On Pointer Comparisons
>:   ----------------------
[..]
>:    Allocations by 'new' of empty classes will then require at least one
>:    byte of address space be wasted, otherwise
>[...]
>:    Inclusion of an empty class in a structure must also have this
>:    property,[...]
>
>==>    Only if adjacent to another member with which it has a common
>    base class.

    Can you have the size different depending ... Yes,
Ok, the size could be zero, and the position of the next object
might be adjusted if required and not otherwise.

>
>: Alternative.
>
>:    The alternative rule allows an exception if the classes are empty,
>:    empty meaning either no data members, or better, no data members
>:    and no virtual functions.
>
>==>    "no virtual functions" is perhaps too restrictive, since that

    Yes.

>    I think "no data members" must be enough to void all
>    guarantees on pointer distinctness (in this alternative
>    to rule (1)).
>    I think the alternate rule (1) must be
>
>    "You can't rely on pointer equivalence for classes that have
>    no data members"

    Fine.
>
>    disqualifying among others many abstract base classes (I know
>    you John like MI mix-ins, many of those should be affected too).

    Well, that just means you want rule(1) and not rule(1A).
There has been disagreement on this so I didnt want to preempt the
outcome here by making a decision. But likely rule 1 will do
because ARM requires non-zero length objects doesnt it?
>
>[ definition of "domestic" pointers deleted ]

    I think you mean "definition" of domestic pointers deleted :-)

>
>:    Two void* compare equal if they were derived from the two
>:    valid domestic pointers that compare equal, and those
>:    pointer values remain valid.
>
>==>    Two void* should also be allowed to compare equal in

    you must mean "required" not "allowed" surely?

>    cases where they are not derived from two domestic
>    pointers that compare equal, i.e.
>
>    p1==p2  ==>  (void*)p1==(void*)p2,

    Maybe. And maybe this rule is totally wrong!
Consider

    class A {} class B : A {}
    B* b=new B;
    A* a=b;
    a==b; // YES after implicit conversion of b to an A
    (void*)a == (void*)b; // NO, they point different places

So I think unless I'm wrong here and right before this rule has to
be withdrawn :-(

>
>    but not the other way around.  The reverse should only hold
>    if (p1 == p2) is defined, assuming equality comparison
>    is only defined if p1 and p2 are of the same type, or share
>    a common base class.

    I assume you can only compare pointers of exactly the same
type. All other comparisons must convert one of the pointers first.

>
>    Also note that the common base class of p1 and p2 must not
>    be an empty class (if the alternative rule (1) is adopted).
>
>: Comment
>
>:    The desired equivalence
>
>:    a==b <==> a,b refer to the same object
>:    a!=b <==> a,b refer to different objects
>
>:    is subject to the 3 constraints:
>
>:    a) nonempty class (if rule 1 alternative is taken)
>:    b) validity (continued existence of the object pointed to)
>:    c) domesticity (exclusion of mangling and foreign suppliers)
>
>==>    I like the analysis, although I think constraint a) should
>    be removed, since all classes with no data members must be
>    considered "empty".

If "empty" classes are zero length, you need the caveat, otherwise
you dont.

I really dont know if this sort of thing is viable for the Standard.
The whole of this was to allow certain types of code to be
non-strictly conforming without being non-conforming.

In particular, it might perhaps *allow* vendor supplied
standard routines to muck with pointers without making
programs written using these features non-conforming.
(E.g. Borland and most DOS systems allow construction
and manipulation of pointers with language extensions.).

But I think really all bets might be off. You would
have to replace /pointer/ with /domestic pointer/
throughout most of the standard, eg

    x->print(); // x has to be domestic

and what it might ome down to is that all pointers
are assumed domestic in the standard anyhow .. so there
is nothing really to say. Sigh. I'm learning.
Never thought comparing two pointers would be so
hard to understand .. I do it now and then with no great qualms :-)

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