home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11547 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  2.2 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!allegra!alice!ark
  2. From: ark@alice.att.com (Andrew Koenig)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Renew?
  5. Message-ID: <23315@alice.att.com>
  6. Date: 25 Jul 92 18:27:40 GMT
  7. Article-I.D.: alice.23315
  8. References: <1992Jul3.171226.10277@taumet.com> <1992Jul3.201320.26801@well.sf.ca.us> <1992Jul4.173316.11890@taumet.com> <1992Jul5.002414.390@frumious.uucp> <THOTH.92Jul25110048@wave.cis.ufl.edu>
  9. Reply-To: ark@alice.UUCP ()
  10. Organization: AT&T Bell Laboratories, Liberty Corner NJ
  11. Lines: 40
  12.  
  13. In article <THOTH.92Jul25110048@wave.cis.ufl.edu> thoth@wave.cis.ufl.edu (Robert Forsman) writes:
  14.  
  15. > The absence of an analog for realloc is one of my MAJOR gripes with
  16. > C++
  17.  
  18. So make a proposal.  I and several other people have thought about
  19. it from time to time but so far I have not seen a proposal I like.
  20.  
  21. There is also the problem that it is potentially very difficult to
  22. implement in a C-based environment if it is required to use realloc.
  23. The trouble is that you can't tell whether realloc will move something
  24. until after it's too late.
  25.  
  26. >   It is.  If they're too busy considering other stuff, they can put it
  27. > on hold.  This is more important.
  28.  
  29. It may be more important to you; it is probably not more important
  30. to most of the committee members.  For example, I do not think anyone
  31. has actually sent in a proposal for it.
  32.  
  33. >   Well, I'm not sure I like that.  I'd much rather see a bcopy instead
  34. > of a copy construction and a deletion in almost every case (almost).
  35. > I may have missed the discussion about why this is bad.
  36.  
  37. If I write a copy constructor in my class, I expect that constructor
  38. to be called when an object of that class is copied.  Period.
  39.  
  40. >   Why not have ANOTHER special method (in addition to copy
  41. > construction, deletion and assignment) which is only called when an
  42. > object is being MOVED from one memory location to another?
  43.  
  44. That is much too much added complexity for one special case.  I can
  45. confidently guarantee that if such a feature were added, the majority
  46. of C++ programs would either misuse it or forget to use it altogether.
  47.  
  48. Simple things are hard enough without looking for more ways of
  49. complicating them.
  50. -- 
  51.                 --Andrew Koenig
  52.                   ark@europa.att.com
  53.