home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11809 < prev    next >
Encoding:
Text File  |  1992-07-30  |  1.5 KB  |  33 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Renew?
  5. Message-ID: <1992Jul30.172824.7760@microsoft.com>
  6. Date: 30 Jul 92 17:28:24 GMT
  7. Organization: Microsoft Corporation
  8. References: <memo.547224@cix.compulink.co.uk> <23347@alice.att.com>
  9. Lines: 22
  10.  
  11. In article <23347@alice.att.com> ark@alice.UUCP () writes:
  12. |If renew guarantees to the user that the copy constructor and
  13. |destructor will be called for each object moved, that greatly
  14. |ameliorates the situation.  It is then sufficient for the user to
  15. |get those two functions right, or make them private (which would
  16. |prohibit renew on objects of that class).
  17.  
  18. Not sufficient, also the programmer has to make sure not to have
  19. any interior pointers to objects in the array.  Because C++ *still* wouldn't
  20. have support for "move"able objects.  What it would have then would be 
  21. support for constructing a new array of objects based on a previous 
  22. array of objects which are destroyed in the process.
  23.  
  24. For C++ to allow programmers to "move" objects would require language
  25. support for identifying pointers at runtime, and "patching" those pointers
  26. and/or refs to refer to objects' new locations.  This is a good idea IMHO, 
  27. and is necessary for effective GC and OODB.  The central problem then becomes
  28. the inability to support the historic "C" hack of casting pointers to/from
  29. ints.  This problem and others lead to the idea that such an approach would
  30. require a Modula-3-like split of the C++ programming world into "safe" 
  31. verses "unsafe" parts.
  32.  
  33.