home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1785 < prev    next >
Encoding:
Text File  |  1992-12-15  |  2.5 KB  |  52 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Pointer comparisons and templates
  5. Message-ID: <9235019.16384@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <1992Dec8.103218.27689@lth.se> <1992Dec8.173855.18153@meaddata.com> <1992Dec9.075125.22405@lth.se> <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.075853.3399@lth.se>
  9. Date: Tue, 15 Dec 1992 08:50:09 GMT
  10. Lines: 40
  11.  
  12. dag@bellman.control.lth.se (Dag Bruck) writes:
  13.  
  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. >While I think ptrcmp() is better than nothing, I still think extending
  21. >the definition of the relational operators is far better.
  22. [...]
  23. >3.  The programmer using class Tree must remember to use a different
  24. >class for pointers.  There is no type checking that prevents the user
  25. >from using Tree<Foo*> -- it will compile fine but produce the wrong
  26. >results on some machines.
  27. [...]
  28. >I regard (3) is biggest problem, in particular as there is no way (as
  29. >far as I know) to diagnose the problem.   It may work fine on some
  30. >machines, and then break when you port the code to a new machine or a
  31. >new memory model on the same machine.
  32.  
  33. The problem is that there are two different sorts of "ordering" operations
  34. that are useful in different circumstances. The first is comparing
  35. pointers to objects in the same array, the second is comparing arbitrary
  36. pointers. On some architectures, the former is much faster than the latter.
  37.  
  38. Extending the definition of the relational operators would make many programs
  39. considerably less efficient, break some conformant but not strictly conformant
  40. programs, and would create more problems than it would solve, IMHO.
  41.  
  42. Although ptrcmp() is not a perfect solution as far as template data-structures
  43. go, the alternative would also have difficulties -- what if I want a Tree
  44. of pointers all of which _are_ in the same array, and efficiency is
  45. very important? In that case, Tree<Foo*> is exactly what I want.
  46.  
  47. -- 
  48. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  49. This .signature virus is a self-referential statement that is true - but 
  50. you will only be able to consistently believe it if you copy it to your own
  51. .signature file!
  52.