home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19919 < prev    next >
Encoding:
Text File  |  1993-01-27  |  2.2 KB  |  45 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!math.fu-berlin.de!ira.uka.de!slsvaat!josef!kanze
  3. From: kanze@us-es.sel.de (James Kanze)
  4. Subject: Re: Overloading Operators
  5. In-Reply-To: krc@wam.umd.edu's message of Mon, 25 Jan 1993 17:48:19 GMT
  6. Message-ID: <KANZE.93Jan26175302@slsvdnt.us-es.sel.de>
  7. Sender: news@us-es.sel.de
  8. Organization: SEL
  9. References: <727392166snx@trmphrst.demon.co.uk> <C13BK9.Lr@frumious.uucp> <2215@celia.UUCP>
  10.     <1993Jan25.174819.18445@wam.umd.edu>
  11. Date: 26 Jan 93 17:53:02
  12. Lines: 31
  13.  
  14. In article <1993Jan25.174819.18445@wam.umd.edu> krc@wam.umd.edu (Kevin
  15. R. Coombes) writes:
  16.  
  17. |> In article <2215@celia.UUCP> celia!gray@usc.edu (Steve Gray) writes:
  18. |> >A const reference differs in a very important way from a plain reference:
  19. |> >it clearly states that the member function has no side effects.  One of
  20. |> >my (and others at R&H's) primary objections to using references is that
  21. |> >it means member functions can have un-obvious side effects on their parameters. 
  22. |> >i.e. they can change the contents of a variable which was passed by value (as 
  23. |> >far as the caller's syntax is concerned) and therefor should not be changed by 
  24. |> >the member function.
  25. |> >
  26. |> >We have basically outlawed non-const references as being too dangerous.  I
  27. |> >personally would have preferred that they not even be allowed in the language,
  28. |> >but I can understand why (given the syntax of the language) they are allowed.
  29.  
  30. |> Have you also outlawed pointers (to non-const objects) as parameters?
  31.  
  32. There is a very big difference between using a non-const reference and
  33. a non-const pointer as a parameter.  In the case of the reference, the
  34. *only* place where it is documented that the function might change the
  35. parameter is in the function prototype, which is often quite far from
  36. where the function is being used.  When the parameter is a pointer,
  37. however, the address of the parameter must be taken explicitely when
  38. the function is called, so someone reading the program can see
  39. immediately what the risks are.
  40. --
  41. James Kanze                             email: kanze@us-es.sel.de
  42. GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
  43. Conseils en informatique industrielle --
  44.                    -- Beratung in industrieller Datenverarbeitung
  45.