home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19955 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.5 KB  |  64 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!gatech!darwin.sura.net!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!swillden
  3. From: swillden@news.ccutah.edu (Shawn Willden)
  4. Subject: Re: References to functions?
  5. Message-ID: <1993Jan26.162624.14112@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Reply-To: swillden@cs.weber.edu
  8. Organization: University of Utah Computer Center
  9. X-Newsreader: Tin 1.1 PL3
  10. References: <1k2u7nINNgbc@info2.rus.uni-stuttgart.de>
  11. Date: Tue, 26 Jan 93 16:26:24 GMT
  12. Lines: 50
  13.  
  14. KOCHER@nvdv.e-technik.uni-stuttgart.dbp.de (HARTMUT KOCHER) writes:
  15. : In <1993Jan25.182507.13761@fcom.cc.utah.edu> swillden@news.ccutah.edu writes:
  16. : > : Not exactly. Let's say I have a callback class which takes a pointer
  17. : > : to a function in its constructor. If I use a pointer, a 0-pointer may be
  18. : > : passed. If I use a reference instead, I can make sure, that the user
  19. : > : supplies a valid function.
  20. : > Not really.  Try:
  21. : > typedef int (callbackfunc)(int);
  22. : > extern void set_callback(callbackfunc&);
  23. : > void foo()
  24. : >     {
  25. : >     callbackfunc* callback = 0;
  26. : >     set_callback(*callback);
  27. : >     }
  28. : > : Hartmut Kocher
  29. : > Shawn Willden
  30. : > swillden@icarus.weber.edu
  31. : Sure, but it's always undefined to dereference a 0 pointer.
  32.  
  33. Yes, it is undefined, not illegal.  A compiler could warn about it in
  34. this case, I suppose, but a quick experiment shows that g++ 2.3.3, and
  35. Cfront 3.0.1 accept the above code without complaint and there are
  36. many situations in which the compiler couldn't know.
  37.  
  38. : With a reference you always clearly state, that you are 
  39. : expecting a valid object/function, etc.
  40.  
  41. This is true, as long as you realize that you are only stating that
  42. you expect a valid object/function.  You are not forcing the the user
  43. to supply a valid argument, which was what I understood your intent to
  44. be.
  45.  
  46. : Therefore, it's the callers responsibility to make sure he's passing a valid
  47. : argument, whereas with pointers, the function implementor has to check for
  48. : 0 pointers, because these are allowed by the language.
  49.  
  50. It's always the caller's responsibility to pass a valid argument.  I
  51. agree that passing a reference *should* make it clear to the user that
  52. he needs to pass a valid function.  If you intended the reference
  53. parameter to be a reminder then I agree.  This is, however, a
  54. strictly stylistic thing, not an example of a need for function
  55. references.  Now, if we had a way to impose run-time checks on the
  56. validity of pointers that are dereferenced and cast to references...
  57.  
  58. : Hartmut Kocher
  59.  
  60. --
  61. Shawn Willden
  62. swillden@icarus.weber.edu
  63.