home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 20015 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.2 KB
  1. Path: sparky!uunet!charon.amdahl.com!netcomsv!netcomsv!ulogic!hartman
  2. From: hartman@ulogic.UUCP (Richard M. Hartman)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: References to functions?
  5. Message-ID: <930@ulogic.UUCP>
  6. Date: 27 Jan 93 19:34:48 GMT
  7. References: <1k2u7nINNgbc@info2.rus.uni-stuttgart.de> <1993Jan26.162624.14112@fcom.cc.utah.edu>
  8. Organization: negligable
  9. Lines: 68
  10.  
  11. In article <1993Jan26.162624.14112@fcom.cc.utah.edu> swillden@cs.weber.edu writes:
  12. |KOCHER@nvdv.e-technik.uni-stuttgart.dbp.de (HARTMUT KOCHER) writes:
  13. |: In <1993Jan25.182507.13761@fcom.cc.utah.edu> swillden@news.ccutah.edu writes:
  14. |: > : Not exactly. Let's say I have a callback class which takes a pointer
  15. |: > : to a function in its constructor. If I use a pointer, a 0-pointer may be
  16. |: > : passed. If I use a reference instead, I can make sure, that the user
  17. |: > : supplies a valid function.
  18. |: > Not really.  Try:
  19. |: > typedef int (callbackfunc)(int);
  20. |: > extern void set_callback(callbackfunc&);
  21. |: > void foo()
  22. |: >     {
  23. |: >     callbackfunc* callback = 0;
  24. |: >     set_callback(*callback);
  25. |: >     }
  26. |: > : Hartmut Kocher
  27. |: > Shawn Willden
  28. |: > swillden@icarus.weber.edu
  29. |: 
  30. |: Sure, but it's always undefined to dereference a 0 pointer.
  31. |
  32. |Yes, it is undefined, not illegal.  A compiler could warn about it in
  33. |this case, I suppose, but a quick experiment shows that g++ 2.3.3, and
  34. |Cfront 3.0.1 accept the above code without complaint and there are
  35. |many situations in which the compiler couldn't know.
  36.  
  37. The fact remains that you have to pull a convoluted trick to
  38. get this result.  If you do things like that you deserve to 
  39. have your machine seize up when the reference gets used...
  40.  
  41. |: With a reference you always clearly state, that you are 
  42. |: expecting a valid object/function, etc.
  43. |
  44. |This is true, as long as you realize that you are only stating that
  45. |you expect a valid object/function.  You are not forcing the the user
  46. |to supply a valid argument, which was what I understood your intent to
  47. |be.
  48.  
  49. And with a pointer it is frequently allowable (expected even) that
  50. a NULL pointer is allowable under certain circumstances.  With a
  51. reference you are making it clear that you should provide something
  52. valid.
  53.  
  54. |: Therefore, it's the callers responsibility to make sure he's passing a valid
  55. |: argument, whereas with pointers, the function implementor has to check for
  56. |: 0 pointers, because these are allowed by the language.
  57. |
  58. |It's always the caller's responsibility to pass a valid argument.  I
  59. |agree that passing a reference *should* make it clear to the user that
  60. |he needs to pass a valid function.  If you intended the reference
  61.  
  62. Sometimes NULL *is* a valid argument.  A reference argumetn indicates
  63. that it is not.  A pointer argument leaves the point unclear.
  64.  
  65. |parameter to be a reminder then I agree.  This is, however, a
  66. |strictly stylistic thing, not an example of a need for function
  67. |references.  Now, if we had a way to impose run-time checks on the
  68. |validity of pointers that are dereferenced and cast to references...
  69.  
  70. I think the overall benefit makes this more than a stylistic thing.
  71.  
  72.  
  73.         -Richard Hartman
  74.         hartman@ulogic.COM
  75.  
  76. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  77. I am just a figment of your imagination...
  78.             ...what does that say about *your* mental health?
  79.