home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18197 < prev    next >
Encoding:
Text File  |  1992-12-21  |  1.8 KB  |  41 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!caen!spool.mu.edu!umn.edu!csus.edu!borland.com!pete
  3. From: pete@borland.com (Pete Becker)
  4. Subject: Re: Death of Borland C++ Compiler
  5. Message-ID: <1992Dec18.171904.17816@borland.com>
  6. Originator: pete@genghis.borland.com
  7. Sender: news@borland.com (News Admin)
  8. Organization: Borland International
  9. References: <chaolin.88@fcit-m1.fcit.monash.edu.au>
  10. Date: Fri, 18 Dec 1992 17:19:04 GMT
  11. Lines: 28
  12.  
  13. In article <chaolin.88@fcit-m1.fcit.monash.edu.au> chaolin@fcit-m1.fcit.monash.edu.au (CHAOLIN CHANG) writes:
  14. >
  15. >I was a loyal Borland C++ compiler user.  I love the IDE environment 
  16. >(though I only use it for creating the project file) and various tools 
  17. >bundled.  But as my programs are becoming complex (using pointer, pointer 
  18. >to pointer, pointer to pointer to pointer and farmalloc extensively), 
  19. >Borland compiler begins to fall over.  One of my colleagues is also 
  20. >suffering for the same experience when he tried to push the Borland compiler 
  21. >to its limits.
  22. >
  23. >I had pulled all my hair out.  If the program is run within the debuger line 
  24. >by line, it works fine.  But as soon as I let go, it hung my PC.  
  25. >
  26. >I recompile the same source code in Zortech.  It WORKS. 
  27. >
  28. >I wonder if anyone else has the same experiences with me?
  29. >
  30.  
  31.     It is not at all uncommon for buggy programs to appear to work when
  32. compiled with one compiler and to fail with another compiler.  It often means
  33. that the two compilers lay the data out differently, so writing through a
  34. bad pointer happens to be harmless with one compiler and fatal with another.
  35.     I have rarely seen problems of the type described here that can
  36. actually be blamed on the compiler.  Which isn't to say that it can't be a
  37. compiler bug, but that it requires much more investigation.
  38.     -- Pete
  39.  
  40.  
  41.