home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 13176 < prev    next >
Encoding:
Text File  |  1992-09-01  |  2.2 KB  |  50 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!uunet.ca!frumious!pat
  3. From: pat@frumious.uucp (Patrick Smith)
  4. Subject: Re: Destruction of temporaries
  5. Message-ID: <1992Sep2.042030.488@frumious.uucp>
  6. Date: Wed, 2 Sep 1992 04:20:30 GMT
  7. Reply-To: uunet.ca!frumious!pat
  8. References: <rmartin.715101472@thor> <1992Aug29.184025.328@frumious.uucp> <rmartin.715267769@thor>
  9. Organization: None
  10. Lines: 38
  11.  
  12. rmartin@thor.Rational.COM (Bob Martin) writes:
  13. |Some compilers may wish to deal with the deluge of warnings by
  14. |implementing #pragmas which specifically inhibit warnings about the
  15. |creation of aliases as arguments to specific functions.  For example:
  16. |
  17. | #pragma Supress_Alias_Warning String::operator+(const String&, const String&)
  18. |
  19. |This could prevent the compiler from warning about aliases created
  20. |when forming the arguments to functions which are known to be benign.
  21. |The above #pragma would eliminate all the warnings from your example,
  22. |but would still pass warnings about other aliases.
  23. |
  24. |This exposes the alias problem, and puts responsibility for it square
  25. |on the programmer.  It also allows the compiler to destroy temporaries
  26. |at the earliest possible moment.
  27.  
  28. In my code, and I suspect in most people's, the vast majority of
  29. reference parameters to functions fall into one of two categories.
  30. Either it's a reference to non-const, and can't be called with a
  31. temporary for an argument, or it's a reference to const and it's
  32. perfectly safe to call it with a temporary argument.
  33.  
  34. So I think it would be a better idea for the programmer to identify
  35. those functions which can't be called with temporaries as arguments,
  36. instead of those which can.  As, for example, in Eric Smith's
  37. proposal upon which I commented in another posting.
  38.  
  39. One might argue that it is safer to treat functions as 'dangerous
  40. to call with temporary arguments unless otherwise indicated', rather
  41. than 'safe ... unless otherwise indicated'.  But I think this argument
  42. ignores human nature.  If you ask people to flag 19 out of every 20
  43. functions (numbers made up out of thin air) as safe, many of them
  44. will get tired of that and just start ignoring the warning messages.
  45.  
  46. -- 
  47. Patrick Smith
  48. uunet.ca!frumious!pat
  49. pat%frumious.uucp@uunet.ca
  50.