home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / mac / oop / macapp3 / 224 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  3.4 KB
  1. Path: sparky!uunet!stanford.edu!apple!applelink.apple.com
  2. From: GER.XSE0039@AppleLink.Apple.COM (Germany - C Brinkschulte Berlin,IDV)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re:Re: Bug in TDynamicArray
  5. Message-ID: <724522278.5036135@AppleLink.Apple.COM>
  6. Date: 16 Dec 92 15:46:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 81
  10.  
  11. >The problem arises when a TDynamicArray is cloned while an Iterator which was
  12. >used for the TDynamicArray is stil in scope. TDynamicArray has a field named
  13. >fIteratorPtr, which contains a linked list of Iterators currently in use for
  14. >the TDynamicArray. When a TDynamicArray gets cloned, both (the old and the
  15. >cloned Array's) fIteratorPtrs point to the same Iterator. If the
  16. >CArrayIterator
  17. >is destructed, the fIteratorPtr of the cloned TDynamicArray points to an
  18. >invalid Memory-Address.
  19.  
  20. Response:
  21.  
  22. >By golly, you're right!  How they ever let one this obvious slip through
  23. >I'll never know.  TDynamicArray should have a Clone override that sets
  24. >fIteratorPtrs = NULL.
  25.  
  26. >What the heck are you doing that creates a clone of the array while you're
  27. >iterating it?  It seems to me that the only time that linked list of iterators
  28. >get used is when iterations are nested -- unless you are instantiating
  29. >iterators as seperate objects and not by the usual method on the stack.
  30.  
  31.  
  32. *Every* Iterator inserts itself into the linked list of Iterators found inside
  33. TDynamicArray it is attached to. This is necessary, because the Iterators have
  34. to be informed, if an element gets inserted into or deletetd from the Array
  35. while iterating over the Array. They have to be informed, so they can adjust to
  36. the new size of the Array. (A very nice feature, by the way). It is not
  37. necessary to have multiple or nested Iterators to trigger the bug.
  38.  
  39. In fact, it is very easy to run into the problem. The following code is an
  40. example on how _EASY_ it is:
  41.  
  42. TDynamicArray* aDynamicArray = new TDynamicArray;
  43. aDynamicArray->IDynamicArray (0, sizeof (MyStruct));
  44.  
  45. CArrayIterator iter (aDynamicArray);
  46.  
  47. for (   ArrayIndex index = iter.FirstIndex ();
  48.         iter.More ();
  49.         index = iter.NextIndex ())
  50. {
  51.     [do something]
  52. }
  53.  
  54. TDynamicArray* clonedArray = aDynamicArray->Clone ();
  55.  
  56. You dont have to be iterating over the array if you like to run into the
  57. problem. The point is that as long as the Iterator is in scope, (the block the
  58. Iterator was declared), its destructor does _NOT_ get called. So it stays
  59. inside the linked list of Iterators attached to the DynamicArray. This leads to
  60. the conclusion that one never should clone a List or DynamicArray after or
  61. while iterating over the array.
  62.  
  63. Another workaround for this problem is to make a seperate block for the
  64. Iterator so its destructor gets called (which removes itself from the linked
  65. list of Iterators) before cloning the Array:
  66.  
  67. TDynamicArray* aDynamicArray = new TDynamicArray;
  68. aDynamicArray->IDynamicArray (0, sizeof (MyStruct));
  69.  
  70. {   // Extra block to limit the scope of the Iterator
  71.     CArrayIterator iter (aDynamicArray);
  72.  
  73.     for (   ArrayIndex index = iter.FirstIndex ();
  74.             iter.More ();
  75.             index = iter.NextIndex ())
  76.     {
  77.         [do something]
  78.     }
  79. }
  80.  
  81. TDynamicArray* clonedArray = aDynamicArray->Clone ();
  82.  
  83. I think this explains the range of the problem better than my first link.
  84.  
  85. Please send me a copy of any replys, because I am not part of MacAppTech$
  86. anymore (it has flooded my In-Box too much).
  87.  
  88. Carsten Brinkschulte
  89. Berlin
  90. GER.XSE0039
  91.  
  92.