home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1864 < prev    next >
Encoding:
Text File  |  1992-12-21  |  7.6 KB  |  241 lines

  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Pointer Comparisons
  5. Message-ID: <1992Dec20.000341.6417@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. Date: Sun, 20 Dec 1992 00:03:41 GMT
  10. Lines: 229
  11.  
  12.  
  13.   On Pointer Comparisons
  14.   ----------------------
  15.  
  16. I propose, not claiming to be the originator of any or all the ideas
  17. here, that the issue of pointer comparisons be resolved as
  18. follows.
  19.  
  20.  
  21. 1) If two pointers of the same type, (other than void*) compare equal,
  22.    then they may be assumed to refer to the same object, subobject,
  23.    or component.
  24.  
  25. Comment.
  26.  
  27.    Allocations by 'new' of empty classes will then require at least one
  28.    byte of address space be wasted, otherwise
  29.  
  30.  
  31.    struct T {};
  32.    T* t1=new T;
  33.    T* t2=new T;
  34.  
  35.    if(p==q)cout<<"p,q are same object");
  36.  
  37.    gives a false diagnostic.
  38.  
  39.    Inclusion of an empty class in a structure must also have this
  40.    property, as must allocations on the stack or in static storage.
  41.    The same is true for inheritance:
  42.  
  43.    struct U : public T {};
  44.    struct V : public T {}
  45.    struct D : public U, public V { ... } d;
  46.  
  47.    T* t1=(U*)&d;
  48.    T* t2=(V*)&d;
  49.  
  50. Alternative.
  51.  
  52.    The alternative rule allows an exception if the classes are empty,
  53.    empty meaning either no data members, or better, no data members
  54.    and no virtual functions.
  55.  
  56.    This alternative precludes use of empty classes solely to create
  57.    unique objects with no operations, but appears to have no other
  58.    serious consequences. Since nonempty classes can always be
  59.    used to artificially create unique object identities, this
  60.    alternative may be viable.
  61.  
  62. 2) Let T be a type. A pointer to T, const T, volatile T, or
  63.    const volatile T is called an object pointer. Pointers
  64.    to array types are also object pointers.
  65.  
  66.    The address of a function is a function pointer.
  67.  
  68.    A void* is a void pointer.
  69.  
  70.    A pointer obtained by operator new, or taking the address
  71.    of a static or auto object, or a pointer explicitly set to 0,
  72.    is a domestic pointer (value).
  73.    A pointer to a function with external linkage is a domestic
  74.    pointer (value).
  75.  
  76.    A domestic pointer is valid if the object from which it was
  77.    derived continues to exist, otherwise it is said to dangle,
  78.    and is invalid, except that 0 pointers are considered valid.
  79.    (If nested functions are introduced, this rule also applied
  80.    to them. If dynamic linkage is used, this rule also applies to them)
  81.  
  82.    A function or object pointer obtained by conversion, copying,
  83.    or assignment, of a valid domestic pointer is a valid domestic pointer
  84.    (except for conversion to void*, which is not a function or object
  85.    pointer).
  86.  
  87.    If a (valid) member pointer is bound to a valid non-zero
  88.    object pointer, the result is a valid object pointer.
  89.  
  90.    (Appropriate rules for pointers to objects in arrays need
  91.    to be included here, allowing for pointer arithmetic).
  92.  
  93.    Two valid domestic pointers of the same type compare equal if they
  94.    point to the same object or function.
  95.  
  96.    Two void* compare equal if they were derived from the two
  97.    valid domestic pointers that compare equal, and those
  98.    pointer values remain valid.
  99.  
  100. Comment.
  101.  
  102.    These rules explicitly exclude 'foreign' pointers such as those
  103.    obtained by operating system calls. In this case the rules
  104.    may be obeyed or not, it is implementation defined.
  105.  
  106.    The same applies to invalid pointers, since the memory may be
  107.    reclaimed, or the pointers themselves modified by a GC
  108.    or compaction algorithm.
  109.  
  110. 3) Combination of (1) and (2) yield an equivalence between
  111.    object identity and pointer equality subject to the caveats
  112.    mentioned.
  113.  
  114.    Therefore, the inequality operator will be defined by
  115.  
  116.    a!=b <==> !(a==b)
  117.  
  118.    with the same caveats.
  119.  
  120. Comment
  121.  
  122.    The desired equivalence
  123.  
  124.    a==b <==> a,b refer to the same object
  125.    a!=b <==> a,b refer to different objects
  126.  
  127.    is subject to the 3 constraints:
  128.  
  129.    a) nonempty class (if rule 1 alternative is taken)
  130.    b) validity (continued existence of the object pointed to)
  131.    c) domesticity (exclusion of mangling and foreign suppliers)
  132.  
  133. 4) The operators <,>, <=,>= are implementation defined, unless
  134.    the arguments point into the same array or access components
  135.    of the same access section in a class, or both, in which
  136.    case they reflect the relative positions in the obvious
  137.    way (with caveats for empty classes).
  138.  
  139.    (Additional caveats may have to be added here, esp regards
  140.    subobject ordering)
  141.  
  142.    If the macro TOTALPTRORDER is defined, the standard pointer
  143.    comparisons provide a total order.
  144.  
  145. 5) The standard library function
  146.  
  147.    int ptrorder(void*,void*);
  148.  
  149.    yields a total order as follows:
  150.  
  151.    ptrorder(a,a)==0                                       (reflexive)
  152.    ptrorder(a,b)<0 ==> ptrorder(b,a)>0                    (anti-commutative)
  153.    ptrorder(a,b)==0 ==> ptrorder(b,a)==0
  154.    ptrorder(a,b)<0 && ptrorder(b,c)<0 ==> ptrorder(a,c)<0 (transitive)
  155.  
  156.  
  157.    If the macro TOTALPTRORDER is defined, ptrorder must
  158.    provide the same ordering.
  159.  
  160. Comment.
  161.  
  162.    ptrorder may return 0 for all arguments. It can be used in algorithms
  163.    not requiring any object identity, such as sorts, but not when
  164.    equality is required for a uniqeness such as for a b-tree.
  165.  
  166.  
  167. 6) Ptrorder0
  168.  
  169.    Same as ptrorder, with the additional constraint
  170.  
  171.    ptrorder0(0,a)==0 ==> a==0
  172.  
  173. Comment.
  174.  
  175.    This function allows 0 to be distinguished. I'm not sure
  176.    how useful this is, and whether it should be required or
  177.    indicated by a macro variable.
  178.  
  179. 7)  ptrcmp
  180.  
  181.     This function returns a total order compatible with ==
  182.  
  183.     ptrcmp(a,b)==0 <==> a==b
  184.  
  185.     It is implementation dependent whether this function is actually
  186.     provided or not, if it is, however, it must obey the above
  187.     semantics.
  188.  
  189.     To facilitate detection the macro variable PTRCMP is defined
  190.     if ptrcmp is available for unrestricted calls, and not otherwise.
  191.  
  192.     If ptrcmp is not available, the user may supply a ptrcmp routine,
  193.     which must have the above semantics.
  194.  
  195. Comment.
  196.  
  197.     ptrcmp is used when object identity is important, for
  198.     example an efficient set implementation.
  199.  
  200.     If ptrcmp is not available, it is an indication that in this
  201.     environment a client algorithm could not possibly work.
  202.     For example in the presence of an incremental compacter that
  203.     reordered objects in memory and updated the relevant pointers,
  204.     a set implemented by an ordered list could not work,
  205.     so the absence of ptrcmp is no loss.
  206.  
  207. Extension.
  208.  
  209.     The functions
  210.  
  211.     freezeptrcmp()
  212.     thawptrcmp()
  213.  
  214.     may also be supplied in systems where pointers may be silently
  215.     modified.
  216.  
  217.     The macro FREEZEPTRCMP is defined if these functions are defined.
  218.     If the macro PTRCMP is defined, freezing and thawing effects
  219.     efficiency only, calls to freezeptrcmp() and thawptrcmp() are optional.
  220.  
  221.     If FREEZEPTRCMP is defined, but PTRCMP is not, then
  222.     calling freezeptrcmp() enables ptrcmp to yield a total
  223.     order.
  224.  
  225.     After freezptrcmp() is called, the order may be lost.
  226.  
  227.     The freeze function need not stop a compaction routine,
  228.     only prevent it destroying a total order.
  229.  
  230.     If PTRCMP is not defined, freezing is mandatory during
  231.     sequences of calls to ptrcmp. Inappropriate calls
  232.     to ptrcmp may not work if correct freezing and thawing
  233.     strategy is not followed.
  234.  
  235.  
  236. -- 
  237. ;----------------------------------------------------------------------
  238.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  239.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  240. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  241.