home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1791 < prev    next >
Encoding:
Text File  |  1992-12-15  |  3.4 KB  |  88 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: Re: Pointer comparisons and templates
  5. Message-ID: <1992Dec15.164854.13070@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. References: <1992Dec9.075125.22405@lth.se> <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.075853.3399@lth.se>
  10. Date: Tue, 15 Dec 1992 16:48:54 GMT
  11. Lines: 75
  12.  
  13. In article <1992Dec14.075853.3399@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
  14. >In the recent discussion on pointer comparisons, Fergus Hendersson
  15. >suggested adding a standard library function ptrcmp() instead of
  16. >extending the definitions of "<" and ">" for pointers.  I think we
  17. >also agreed on a reasonable relationship between ptrcmp() and the
  18. >relational operators.
  19.  
  20.     I'm not sure we've all agreed on the relationship, if any,
  21. between < and ptrcmp, but I think we agree that
  22.  
  23.     "there will be a library function ptrcmp(void*,void*)
  24.     which defines a total order"
  25.  
  26. unless you can convince us the < is worth more  than
  27. making assumptions about all future machine architectures.
  28.  
  29. >
  30. >Now, here's the problem: this implementation works fine for all
  31. >element types that have an "operator < ()" including plain built-in
  32. >types and many user-defined types.  
  33.  
  34.     No...see below...
  35.  
  36. >However, it is not guaranteed to
  37. >work with pointer elements for reasons we have discussed before.
  38.  
  39.     So clearly it doenst work with arbitrary user defined types
  40. either for precisely the same reason. The user defined type
  41. need not be a total order.
  42.  
  43.     Imagine my suprise when qsort failed! I couldnt
  44. understand it until I realised by definition of < was wrong!
  45.  
  46.     The only way to fix this is to have a proper assertion
  47. mechanism so you  can state that < for type T is a total order.
  48. Gee,   T::operator< could return anything!
  49.  
  50. >
  51. >3.  The programmer using class Tree must remember to use a different
  52. >class for pointers.  There is no type checking that prevents the user
  53. >from using Tree<Foo*> -- it will compile fine but produce the wrong
  54. >results on some machines.
  55.  
  56. >I regard (3) is biggest problem, in particular as there is no way (as
  57. >far as I know) to diagnose the problem.   It may work fine on some
  58. >machines, and then break when you port the code to a new machine or a
  59. >new memory model on the same machine.
  60.  
  61.     There are no constraints on templates that will ensure anything
  62. except the existance of operator <. 
  63.  
  64.     You could always write the progam in terms of cmp(T,T),
  65. not <. The it would work for pointers too, you would just
  66. have to define cmp(T,T) for each type, including pointers,
  67.  
  68.  
  69.     template<class T> int cmp(T a1, T a2){return a1<a2;}
  70.     int cmp(void* a1, void* a2){return ptrcmp(a1,a2)<0;}
  71.  
  72. >
  73. >Any comments or suggestions would be welcome.  I would be particularly
  74. >happy if you could show that I have described a problem that in fact
  75. >does not exist if you use a suitable programming style.
  76.  
  77.     The problem you mention might be solved with 'cmp'.
  78.  
  79.     The real problem cannot be solved at all, namely, for
  80. a user define < or cmp, ensuring it is a total order.
  81. Except of course by paper and pencil proof for each case.
  82.  
  83. -- 
  84. ;----------------------------------------------------------------------
  85.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  86.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  87. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  88.