home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18383 < prev    next >
Encoding:
Text File  |  1992-12-23  |  2.9 KB  |  74 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!psinntp!wrldlnk!usenet
  3. From: "John F. Isner" <wk01696@worldlink.com>
  4. Subject: Re: USL C++ Standard Components - A bug?
  5. In-Reply-To: <1992Dec13.195120.4368@tagsys.com>
  6. Message-ID: <2934249994.1.wk01696@worldlink.com>
  7. Sender: usenet@worldlink.com
  8. Nntp-Posting-Host: 127.0.0.1
  9. Organization: Nomura Research Institute
  10. Date: Thu, 24 Dec 1992 03:00:50 GMT
  11. X-Mailer: WORLDLink (3.11)
  12. Lines: 60
  13.  
  14. >DATE:   Sun, 13 Dec 1992 19:51:20 GMT
  15. >FROM:   Andrew Gideon <andrew@tagsys.com>
  16. >
  17. >I have just started working with the USL/C++ Standard
  18. >Components for a new client.  Already, I may have found
  19. >a very serious problem.  I hope that I'm wrong.
  20. >
  21. >I have been working with the Rogue Wave tools.h++ product for 
  22. >quite a while.  One of the first things that I did was
  23. >construct deep collections from the RW shallow collections.
  24. >It was nice to see that USL had already thought of this
  25. >(USL calls deep collections "object collections" and shallow
  26. >collections "pointer collections" - some people still publish
  27. >implementation {8^).
  28. >
  29. >But in my first set of experiments, I immediately noticed
  30. >that something was wrong with the deep sets in USL.  
  31. >
  32. >When insert()ing objects into a deep set, the copy
  33. >constructor is used to create new instances.  The object
  34. >passed in the insert() method is still owned by the caller
  35. >of insert() - the new copy is held by the set.
  36. >
  37. >But when a deep set is destructed, the contained objects are 
  38. >NOT destructed.  Further, objects that are remove()ed are also 
  39. >not destructed.
  40. >
  41. >I could find no way (w/o unsafe casts) to get around this.  
  42. >(And even with unsafe casts, I doubt that it would work)
  43. >
  44. >This seems like a memory leak.  Am I missing something?
  45. >Help, please?
  46. >
  47. >    Andrew Gideon
  48.  
  49. USL Sets and Set_of_p's (pointer sets) are quite different,
  50. not only in implementation, but in semantics.  A Set_of_p
  51. is implemented using a data structure optimized to support
  52. set operations on void*'s.  The generic wrapper around this
  53. data structure it is merely for type safety, and generates 
  54. no code.  The elements of a Set_of_p are T*'s.  Memory 
  55. management for the T's pointed to by the Set_of_p is the
  56. responsibility of the client.  This is stated quite clearly
  57. USL's documentation.
  58.  
  59. USL's Sets and Bags, on the other hand, are containers for 
  60. objects.  As you correctly state, objects inserted into them
  61. are copied using T(const T&).  However the copies ARE fully
  62. managed by the container.  For example, the implementation 
  63. uses a hashing scheme with collision lists;  removing an 
  64. object from a Set is implemented by finding and deleting 
  65. the list node containing the object. when the node is deleted, 
  66. ~T() is invoked.  Destroying the Set destroys all the lists,
  67. hence all the nodes, hence all the objects they contain.
  68.  
  69. I have been using the USL Standard Components for several
  70. years, both inside AT&T and in my current job.  To the best
  71. of my knowedge, they are free of memory leaks.  
  72.  
  73. John Isner
  74.