home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12357 < prev    next >
Encoding:
Internet Message Format  |  1992-08-14  |  3.8 KB
  1. Path: sparky!uunet!olivea!decwrl!deccrl!news.crl.dec.com!pa.dec.com!brister
  2. From: brister@decwrl.dec.com (James Brister)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Reference counting for vectors, (Tony Hansen's book).
  5. Message-ID: <BRISTER.92Aug14170213@tirade.decwrl.dec.com>
  6. Date: 15 Aug 92 00:02:13 GMT
  7. References: <1992Aug14.164719.9719@wuecl.wustl.edu>
  8.     <BRISTER.92Aug14110706@tirade.decwrl.dec.com>
  9.     <TMB.92Aug14232208@arolla.idiap.ch>
  10. Sender: news@PA.dec.com (News)
  11. Organization: DEC Western Software Lab
  12. Lines: 68
  13. In-Reply-To: tmb@arolla.idiap.ch's message of 15 Aug 92 03:22:08 GMT
  14.  
  15. On 15 Aug 92 03:22:08 GMT, tmb@arolla.idiap.ch (Thomas M. Breuel) said:
  16. > In article <BRISTER.92Aug14110706@tirade.decwrl.dec.com> brister@decwrl.dec.com (James Brister) writes:
  17.  
  18. >    On Fri, 14 Aug 1992 16:47:19 GMT, abed@venus.wustl.edu (Abed M. Hammoud) said:
  19. >   > I was trying to implement the vector class using the method suggested
  20. >   > by tony Hansen. i.e reference counting. the following code is taken
  21. >   > from Hansen's book (C++ Answer book). There is some thing that doesn't
  22. >   > seems correct.
  23.  
  24. >    What's not correct? The fact that modifying one variable causes the other
  25. >    to change? If that's not what you want, then this isn't for you, but in the
  26. >    case where you're making multiple copies of the array (as paramaters to a
  27. >    function, for example), then this scheme is great.
  28.  
  29. > Using reference counting to get reference semantics on parameter
  30. > passing is very confusing indeed (sadly, this bad idea seems to
  31. > pervade the C++ literature).
  32.  
  33. Perhaps if it's so pervasive then it's not such a bad idea.
  34.  
  35. parameter passing was only a simple example, there are lots of cases where
  36. multiple objects need to keep track of a piece of data, and unless you're
  37. very sure about who is supposed to delete the data and when (non-trivial
  38. when the system gets complex), you can get yourself into a lot of trouble.
  39. Reference counting can save the day.
  40.  
  41. > I have found it to be much better to give everything (including
  42. > arrays) value semantics and use call-by-reference when I want and mean
  43. > call-by-reference (some special hacks are needed for avoiding
  44.                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  45. > redundant copies on return).
  46.   ^^^^^^^^^^^^^^^^^^^^^^^^^^
  47.  
  48. no comment. The nice this about reference counting is the user of the
  49. handle class treats the handle as if it were the data. He can pass it by
  50. reference if he wants, and nothing is lost. He doesn't need any special
  51. hacks to avoid redundant copies. The data size that is duplicated on
  52. pass-by-value is typically only 1 pointer's worth. It's when copies are
  53. made for some (necessary, not just parameter passing) reason that it
  54. shines.
  55.  
  56. > Using call-by-reference when you mean it is also more efficient than
  57. > having reference counting operate behind the scenes constantly.
  58.  
  59. In simple parameter passing to a function I agree, but, as I mention above,
  60. if knowlege of the data must live beyond the function return, it's not
  61. sufficient (or at least not simple).
  62.  
  63. > If you truly want reference counting semantics, you can easily derive
  64. > it from objects with value semantics using a template class.
  65.  
  66. Huh? Can I see an example?
  67.  
  68. >    [goes on to suggest the use of copy-on-write]
  69.  
  70. > Copy-on-write is not really an option for classes like arrays that
  71. > require high-performance updates. You don't want to pay the price for
  72. > the memory fetch and conditional branch on each array store.
  73.  
  74. If the array copies itself the first time it is written to, then you don't
  75. loose anything except on the first access, and with large data it would be
  76. better to have COW than to duplicate everything to protect against
  77. unintended changes.
  78.  
  79. James
  80. --
  81. James Brister                                           brister@wsl.pa.dec.com
  82. DEC Western Software Lab., Palo Alto, CA                        decwrl!brister
  83.