home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13384 < prev    next >
Encoding:
Text File  |  1992-09-08  |  1.7 KB  |  37 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!stanford.edu!leland.Stanford.EDU!leland!interran
  3. From: interran@uluru.Stanford.EDU (John Interrante)
  4. Subject: Re: Pointer or Reference Arguments
  5. In-Reply-To: rmartin@thor.Rational.COM's message of 7 Sep 92 13:06:25 GMT
  6. Message-ID: <INTERRAN.92Sep7225351@uluru.Stanford.EDU>
  7. Sender: news@leland.Stanford.EDU (Mr News)
  8. Organization: Stanford University
  9. References: <1992Sep7.075249.22855@news.uni-stuttgart.de> <rmartin.715871185@thor>
  10. Date: 7 Sep 92 22:53:51
  11. Lines: 24
  12.  
  13. In article <rmartin.715871185@thor>, rmartin@thor.Rational.COM (Bob Martin) writes:
  14. > |1) Reference arguments are used only when aliasing 
  15. > |occurs and the parameter is used only during the 
  16. > |lifetime of the function. Pointers are used whenever the 
  17. > |function might keep a copy of the pointer for later use, 
  18. > |e.g., store it in a private list.
  19.  
  20. > |2) Reference arguments are used whenever you must supply 
  21. > |a valid object to the function. Pointers are used when 0 
  22. > |might be a valid parameter as well.
  23.  
  24. > My objection to style 1) is that it must compete with zero pointers.
  25. > i.e. an argument which qualifies as a reference under fule 1) might
  26. > still have to be a pointer if it can be zero...
  27.  
  28. What do you do if you have to keep around a pointer to the object for
  29. later use *and* the caller must always supply a valid object?  If you
  30. use a reference parameter, then you have to take the address of the
  31. reference inside your function.  That opens the door for havoc if the
  32. caller unsuspectingly passes a stack-allocated object.  If you use a
  33. pointer parameter in such cases, then I have no objection.
  34. --
  35. John Interrante / interran@uluru.stanford.edu
  36. Computer Systems Laboratory, Stanford University
  37.