home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16525 < prev    next >
Encoding:
Text File  |  1992-11-18  |  4.5 KB  |  94 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!eff!news.byu.edu!ux1!fcom.cc.utah.edu!swillden
  3. From: swillden@news.ccutah.edu (Shawn Willden)
  4. Subject: Re: question on REFERENCES
  5. Message-ID: <1992Nov18.172428.15485@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: University of Utah Computer Center
  8. X-Newsreader: Tin 1.1 PL3
  9. References: <5233@holden.lulea.trab.se>
  10. Date: Wed, 18 Nov 92 17:24:28 GMT
  11. Lines: 81
  12.  
  13. jbn@lulea.trab.se (Johan Bengtsson) writes:
  14. : swillden@news.ccutah.edu (Shawn Willden) writes:
  15. : : kestes@nswc-wo.nswc.navy.mil (Kent Estes) writes:
  16. : : : 
  17. : : : I am working on a function that references objects via id.  Upon finding
  18. : : : an object, it returns a reference to that object.  My question is :
  19. : : : if the object is not found, what is the best way to handle this.  If 
  20. : : : I were returning pointers to objects, all I would have to do is
  21. : : : return NULL.
  22. : : 
  23. : : So return a pointer.  There is no way to return a NULL reference (which
  24. : : is good, if you have a reference you *know* that it refers to something).
  25. : : 
  26. : : If there really is a good reason why you need to return a reference 
  27. : : instead of a pointer you can declare a special object of the return
  28. : : type that is always to be returned in case of error and then compare
  29. : : the address of the returned object with the address of the error 
  30. : : object (or overload operator== and play games with that).  Usually,
  31. : : though, you're better off just returning a pointer.
  32. : 
  33. : I disagree.  The described scheme requires the user to test
  34. : the result of every function call that may fail.  This is error prone,
  35. : and in the case of NULL pointers causes program termination (on
  36. : many machines), if overlooked.  Also, the code tends to be severely
  37. : cluttered with tests for NULL.
  38.  
  39. Agreed.
  40.  
  41. : A better approach (IMHO) is to register errors in an error variable,
  42. : which can be a global variable, or one per object (for member functions).
  43. : The error variable must be explicitly read and reset, before proceeding.
  44.  
  45. How is this different from a test for NULL?  The syntax may be slightly
  46. cleaner but not much is really gained by this approach.  Something must
  47. still be returned and that something will be invalid if the function 
  48. fails.  Why is the programmer more likely to remember to test an error
  49. flag than to test a returned pointer against NULL?  It can be argued 
  50. that a program should halt for a serious programmer error such as this
  51. so as to help the debugging process.  There is one advantage to an error 
  52. flag, of course.  You can provide the user with information about why 
  53. the function failed which is useful if there is more than one possible 
  54. reason for failure.  Where this is true I would recommend your approach.
  55.  
  56. : The iostream library uses this approach, guaranteeing that all operations
  57. : on a stream are ignored until the error is fixed.  The advantage is
  58.  
  59. Where applicable, this is probably the best way (barring exceptions,
  60. which few of us have -- yet).  It ensures that nothing extremely bad
  61. will happen until the error status is cleared.  In the case of a 
  62. function that returns an object, however, how do you prevent the 
  63. object returned from being used?  You must include a flag in the object
  64. that indicates the goodness of the state of the object.  This is 
  65. reasonable in some cases, not in others, depending on how serious
  66. the failure is (i.e. maybe the error is such that even an invalid
  67. object cannot be constructed).  In addition, it requires all code
  68. that uses an object to test its goodness and then take appropriate
  69. action if not.  In many cases it is more convenient to design
  70. the object such that a given instance is always valid and to just avoid
  71. creating invalid ones.
  72.  
  73. : that it is OK to omit some error tests, several function calls may
  74. : safely be made before testing for errors.
  75.  
  76. Many times beginning C++ programmers get the idea that pointers are
  77. the `C' way to do things and references are the `C++' way (implying
  78. that pointers should not be used in `real' C++ code).  I was trying
  79. to point out to the original poster that pointers have their place.
  80.  
  81. : Of course, true C++ exceptions is the superior alternative (:-).
  82.  
  83. Someday...
  84.  
  85. : -- 
  86. : --------------------------------------------------------------------------
  87. : | Johan Bengtsson, Telia Research AB, Aurorum 6, S-951 75 Lulea, Sweden  |
  88. : | Johan.Bengtsson@lulea.trab.se; Voice:(+46)92075471; Fax:(+46)92075490  |
  89. : --------------------------------------------------------------------------
  90.  
  91. --
  92. Shawn Willden
  93. swillden@icarus.weber.edu
  94.