home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1795 < prev    next >
Encoding:
Text File  |  1992-12-15  |  2.2 KB  |  53 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Pointer comparisons and templates
  5. Message-ID: <1992Dec15.200112.26463@microsoft.com>
  6. Date: 15 Dec 92 20:01:12 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Dec9.075125.22405@lth.se> <1992Dec12.154918.2220@ucc.su.OZ.AU> <1992Dec14.075853.3399@lth.se>
  9. Lines: 42
  10.  
  11. In article <1992Dec14.075853.3399@lth.se> dag@bellman.control.lth.se (Dag Bruck) writes:
  12. |        if (element < root->element)
  13. |            return InsertElement(root->left, element);
  14. |        if (root->element < element)
  15. |            return InsertElement(root->right, element);
  16. |        return root->element;
  17. |    }
  18. |
  19. |Note that a copy of the element argument is inserted into the tree,
  20. |and that InsertElement() always returns a reference to this copy.
  21. |
  22. |Now, here's the problem: this implementation works fine for all
  23. |element types that have an "operator < ()" including plain built-in
  24. |types and many user-defined types.  However, it is not guaranteed to
  25. |work with pointer elements for reasons we have discussed before.
  26.  
  27. I disagree.  Consider an implementation that fully implements a "strict"
  28. interpretation of IEEE doubles.  Such an implementation fails to "work"
  29. for exactly the same reason as the pointer implementations in question.
  30. Namely your implementation assumes "<" always returns an ordering, 
  31. but neither IEEE doubles, PC pointers, nor user implemented classes
  32. may interpret "<" in such a manner.  In the case of PC pointers all
  33. pointers must be to the same array for your code to work.  In the
  34. case of a strict implementation of IEEE numbers there better not be
  35. any NANs presented to this code.  In the case of user implemented
  36. classes, god only knows what "<" might mean -- I/O an element up
  37. the wazoo, for all we know!
  38.  
  39. This is not an issue of "<" at all, rather it is an issue of templates.
  40. Templates in C++ are the equivalent to "accidental reuse" in Smalltalk.
  41. If the syntax fits, you've got a template class, no matter that the
  42. semantics don't work.  No matter how slow you make pointers, you still
  43. are left with this template "accidental reuse" problem.
  44.  
  45. ======
  46.  
  47. "Trust the programmer."
  48.  
  49. "Make it fast, even if it is not guaranteed to be portable."
  50.  
  51. -- The ANSI-C Rationale
  52.  
  53.