home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 18206 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.8 KB  |  62 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!ais.org!draper
  3. From: draper@ais.org (Patrick Draper)
  4. Subject: Re: Death of Borland C++ Compiler
  5. Message-ID: <BzH1LF.9yA@ais.org>
  6. Organization: UMCC
  7. References: <chaolin.88@fcit-m1.fcit.monash.edu.au>
  8. Date: Fri, 18 Dec 1992 20:15:13 GMT
  9. Lines: 51
  10.  
  11. In article <chaolin.88@fcit-m1.fcit.monash.edu.au> chaolin@fcit-m1.fcit.monash.edu.au (CHAOLIN CHANG) writes:
  12. >bundled.  But as my programs are becoming complex (using pointer, pointer 
  13. >to pointer, pointer to pointer to pointer and farmalloc extensively), 
  14. >Borland compiler begins to fall over.  One of my colleagues is also 
  15. >suffering for the same experience when he tried to push the Borland compiler 
  16. >to its limits.
  17. >
  18. >I had pulled all my hair out.  If the program is run within the debuger line 
  19. >by line, it works fine.  But as soon as I let go, it hung my PC.  
  20. >
  21. >I recompile the same source code in Zortech.  It WORKS. 
  22. >
  23. >I wonder if anyone else has the same experiences with me?
  24. >
  25. >Charles
  26. >18/12/92
  27. >
  28.  
  29. The Borland compiler is reliable for programs of almost any complexity. I
  30. imagine there are some limits of loop nesting, etc, but if you reach thouse
  31. you almost certainly are doing something wrong.
  32.  
  33. In your case, it sounds like you've got memory bugs. The fact that you're
  34. using pointer->pointer->pointer type expressions indicates to me a hard to
  35. debug program. The compiler shouldn't have any trouble with these, I've
  36. never had these problems at all.
  37.  
  38. Try using the 80386 debugger. It loads the program into the same memory
  39. address as DOS does from the command line. Any location dependent errors
  40. will show up as they do without the debugger.
  41.  
  42. The program when compiled with Zortech also will have the same bugs as those
  43. existant under Borland, the difference might be segment ordering (different
  44. program arrangement) under the different compiler. Bugs that clobber unused
  45. memory are still bugs, even if the effects are not obvious.
  46.  
  47. By the way, I DO know what I'm talking about because my current project at
  48. work is a Point of Sale package that is over 70,000 lines long and requires
  49. a DOS extender to run. It is compiled under Borland C++ 2.0 and 3.1.
  50.  
  51. ---One more thing, you might want to try the DOS extender included with
  52. Zortech because it will help show your memory bugs. Development with a DOS
  53. extender is much much better than plain old unextended DOS.
  54.  
  55.  
  56. ------------------////////////////////\\\\\\\\\\\\\\\\\\\\------------------
  57. | Patrick Draper-ZBT       Disclaimer:  I can't control my fingers,        |
  58. | draper@umcc.ais.org                   I can't control my toes! - Ramones |
  59. | University of Michigan Computer Club                                     |
  60. NO CARRIER                     We are a nation of laws, not people         |
  61. ------------------\\\\\\\\\\\\\\\\\\\\////////////////////------------------
  62.