home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / cplus / 1595 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  3.7 KB
  1. Path: sparky!uunet!mcsun!sunic!hagbard!loglule!jbn
  2. From: jbn@lulea.trab.se (Johan Bengtsson)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Recursive templates
  5. Message-ID: <5231@holden.lulea.trab.se>
  6. Date: 18 Nov 92 12:00:57 GMT
  7. References: <BxvtxB.CqA@cs.uiuc.edu>
  8. Organization: Telia Research AB, Aurorum 6, 951 75 Lulea, Sweden
  9. Lines: 73
  10. X-Newsreader: Tin 1.1 PL4
  11.  
  12. pjl@cs.uiuc.edu (Paul Lucas) writes:
  13. : In <5225@holden.lulea.trab.se> jbn@lulea.trab.se (Johan Bengtsson) writes:
  14. : 
  15. : >pl2440@meibm31.cen.uiuc.edu (Paul Jay Lucas) writes:
  16. : >: In <1992Nov16.220526.21566@borland.com> pete@borland.com (Pete Becker) writes:
  17. : >: 
  18. : >: >In article <83733@ut-emx.uucp> jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:
  19. : >: >>Has ANSI decided anything about the expansion of a recursive template
  20. : >: >>definition?
  21. : >: 
  22. : >: *****>    Has anyone got a *real* justification for this?  This is a very
  23. : >:     obfuscated way of writing factorial.
  24. : 
  25. : >You should be able to base binary trees on unary trees (which are degenerate
  26. : >trees more commonly known as linked lists), trinary trees could be
  27. : >based on binary trees, and n-ary trees could be based on (n-1)-ary trees.
  28. : 
  29. : *****>    I'm not convinced.  List, or unary trees as you call them, serve
  30. :     different purposes than do binary trees.  A List class would
  31. :     have "list-type" operations on it;
  32.  
  33. Agreed.  A full-blown List class is more than a unary tree.  Still,
  34. the operations on unary trees map nicely to the operations on lists:
  35. Child(0) --> next(), parent() --> prev(), top() --> first(),
  36. leftMostBottom() --> last(),
  37. in case you really want to integrate the List and Tree concepts.
  38.  
  39. : a BinaryTree class could have
  40. :     LeftChild() and RightChild() functions and wouldn't have
  41. :     list-type operations.
  42.  
  43. In this context, a binary tree is instantiated as GenericTree<2>,
  44. and has Child(0) and Child(1) functions instead.  Deriving class
  45. BinaryTree from GenericTree<2> is trivial. BinaryTree::LeftChild()
  46. and RightChild() just forwards the request to GenericTree<2>::Child().
  47. I would think it is difficult to make GenericTree<2> as efficient
  48. as a hand-crafted class BinaryTree though (but that is not my point).
  49.  
  50. :     
  51. :     Anyway, a Tree<class T,int noOfChildren> class can be
  52. :     implemented nicely without recursive templates; I don't see that
  53. :     the recursive definition buys you anything.
  54.  
  55. A bit stricter type checking.  Typing errors are caught at compile-time
  56. rather than at run-time.  I sure don't need this for may everyday work,
  57. but who knows what tomorrows programmers might need?
  58.  
  59. You lose performance though; at least I think that the recursive version
  60. is difficult to get as fast at child lookup.
  61.  
  62. : >N-dimension matrixes should be possible to base on N-1-dimension matrixes,
  63. : >with 1-dimensional matrixes (arrays) as the recursion-stopper.
  64. : 
  65. : *****>    What's a 5x3 matrix based on?  4x2, 3x1, 2x(oops!).
  66.  
  67. No, no.
  68.  
  69. You don't parameterize on the _size_ of the matrixes, you parameterize
  70. on the number of dimensions.  5x3, 4x2 and 3x1 are all of type
  71. GenericMatrix<2>.  Parameterizing (non-recursively) on the size in each
  72. dimension may be an a useful exercise, if you do a lot of matrix work
  73. (I don't).
  74.  
  75. Whether these recursive template definitions are really useful in
  76. practical work is an open issue, but as someone pointed out, current
  77. template compilers (some) support it, and why not?  It does give added
  78. power to detect type errors at compile-time, rather than at run-time.
  79.  
  80. -- 
  81. --------------------------------------------------------------------------
  82. | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  83. | Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
  84. --------------------------------------------------------------------------
  85.