home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / mswindo / programm / misc / 4295 < prev    next >
Encoding:
Text File  |  1992-12-16  |  2.8 KB  |  78 lines
  1. Newsgroups: comp.os.ms-windows.programmer.misc
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!malgudi.oar.net!news.ans.net!cmcl2!panix!rryan
  3. From: rryan@panix.com (Rob Ryan)
  4. Subject: Re: Borland and Memory
  5. Message-ID: <1992Dec16.182513.5844@panix.com>
  6. Date: Wed, 16 Dec 1992 18:25:13 GMT
  7. Distribution: usa
  8. References: <1gilfkINNjmd@crcnis1.unl.edu> <BzA2sp.199@newsserver.technet.sg> <BzAyI5.BrH@world.std.com> <1992Dec15.144205.16197@mksol.dseg.ti.com>
  9. Organization: Panix, NYC
  10. Lines: 66
  11.  
  12. In <1992Dec15.144205.16197@mksol.dseg.ti.com> duitz@mksol.dseg.ti.com (mitchel n duitz) writes:
  13.  
  14. >I seem to have a point in my code, where I am stuck.
  15. >
  16. >I do a lot of new and delete inside my code, and first,
  17. >I do see a memory leak somewhere, but I can;t pin it down.
  18. >
  19. >The problem I have is that the program just spins.  This
  20. >can happen in two different places - either when I declare ofstream ofs(name),
  21. >or when I'm in a loop allocating a 2 dimensional array - similar to the
  22. >following
  23. >
  24. > [ ... code deleted ... ]
  25.  
  26. As recommended by another user, make sure that you're using a memory model
  27. large enough to support all the data you're using.  Also, make sure you
  28. check the results of the "new" allocation so you can determine if everything
  29. works or not, and report a failure when it does occur.
  30.  
  31. I wanted to try this out, though, and got some curious results.  I initially
  32. tried Borland's EasyWin and kept on getting GPFs.  So, while the command
  33. line versions of Borland C++ v3.1 and MSC v7.0 dealt with the following code
  34. fine (reporting errors allocating at row 14, which makes sense given how
  35. much data I'm allocating).  And when I tried from Windows, Microsoft's
  36. QuickWin worked fine, too (reporting allocation failure at row 12, which
  37. also makes sense due to overhead of Windows processing).  What failed to
  38. work was Borland's EasyWin.  It got a GPF when I tried this program with it.
  39. I don't know why, though, since the code seems safe.  I presume this is a
  40. bug in EasyWin's memory allocation routines.
  41.  
  42. Assuming that you're not using EasyWin, you'd presumably want something
  43. like the following.  Incidentally, when I decrease the numbers to 150 and
  44. 30, the program works without incident.  And I don't know why the ofstream
  45. would be causing a problem.  Have you tried running the code through a
  46. debugger and seeing where the problem occurs?
  47.  
  48. -------------------------------- cut here --------------------------------
  49.  
  50. #include <iostream.h>
  51.  
  52. const long MAXX = 1000;
  53. const long MAXY = 1000;
  54.  
  55. main()
  56. {
  57.     float **pn = new float *[MAXX];
  58.  
  59.     if (!pn) {
  60.         cerr << "failed initial allocation";
  61.         return -1;
  62.     }
  63.  
  64.     for (int i = 0; i < MAXX; i++) {
  65.         pn[i] = new float[MAXY];
  66.         if (!pn[i]) {
  67.             cerr << "failed allocation of row " << i << endl;
  68.             return -2;
  69.         }
  70.     }
  71.  
  72.     return 0;
  73. }
  74.  
  75. -- 
  76.  Rob Ryan
  77.     rryan@panix.com
  78.