home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18368 < prev    next >
Encoding:
Text File  |  1992-12-23  |  1.5 KB  |  47 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!wingnut!pauljo
  3. From: pauljo@microsoft.com (Paul Johns)
  4. Subject: Re: Bug in BC/C++ 2.0 ?
  5. Message-ID: <1992Dec23.202206.29576@microsoft.com>
  6. Date: 23 Dec 92 20:22:06 GMT
  7. Organization: Microsoft:  Redmond, Washington, USA
  8. Keywords: bugs
  9. References: <rogerl.724699309@Minsk> 
  10. Lines: 35
  11.  
  12. What's happening here is that the rules in C++ changed
  13. AFTER the Borland 2.0 compiler was written.
  14.  
  15. In the old (before AT&T 2.1, I believe) days, you had
  16. to specify the size of the array you were deleting.
  17. And you had to get it right.  The old Borland compiler
  18. is compatible with this old rule.
  19.  
  20. So "delete [] ..." is not legal for your compiler.
  21. You have to supply a the size of the array between
  22. the []'s.
  23.  
  24. An alternative that was used in the past was to omit
  25. the []'s entirely if the array was an array of a built-in
  26. type.
  27.  
  28. I **DO NOT** recommend this.  If you do this, the compiler
  29. will generate a delete for a single object, not an array
  30. of objects.  Using the wrong semantics for delete gives
  31. undefined behavior.
  32.  
  33. What I do recommend is that you either:
  34.  
  35. 1.  Upgrade your compiler to one that's AT&T 2.1-compliant.
  36.     I think you should consider Microsoft C++, but I
  37.     work for Microsoft and own Microsoft stock, so I
  38.     have a clear bias.  :)
  39.  
  40. 2.  Put the size in the delete.  This is upwards-compatible:
  41.     it's ignored in AT&T 2.1 and 3.0.  This can be a little
  42.     bit of a pain, but it's probably cheaper than upgrading.
  43.  
  44. Good luck!
  45.  
  46. // Paul Johns
  47.