home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / mswindo / programm / tools / 530 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  1.5 KB
  1. Path: sparky!uunet!mcsun!uknet!uos-ee!mcs.surrey.ac.uk!(null)
  2. From: css1he@mcs.surrey.ac.uk (Hani El-Sakkout)
  3. Newsgroups: comp.os.ms-windows.programmer.tools
  4. Subject: Re: BC++ 3.1 Memory Alloc Problem
  5. Message-ID: <1992Jul21.103609.21192@EE.Surrey.Ac.UK>
  6. Date: 21 Jul 92 10:36:09 GMT
  7. References: <1992Jul20.094558.20975@EE.Surrey.Ac.UK> <1992Jul20.220044.14222@thunder.mcrcim.mcgill.edu>
  8. Sender: news@EE.Surrey.Ac.UK
  9. Organization: University of Surrey, Guildford, England
  10. Lines: 26
  11.  
  12.  
  13. Thanks for your follow-up, Leying..
  14.  
  15. |> You use 'new' to allocate memory. The one you use is borland classlib's
  16. |> class Object new. It redefined. Actually, it is the same with system
  17. |> 'new'. Windows convert it to LocatAlloc(). 
  18.  
  19. I *think* this is true only when using the small and medium memory 
  20. models, but in the Large memory model (the Borland's manuals say that)
  21. heap allocations are from the Global heap.  The Borland's technical
  22. support people also confirmed this by saying that my module definition
  23. file heap-size settings should have absolutely no effect because there
  24. is no local heap in the Large memory model!
  25.  
  26. Which brings me to another question - do the module definition 
  27. settings used during the production of library and DLL files
  28. have any effect on the final .EXE?  I doubt it, but you never 
  29. can tell..
  30.  
  31. Anywaym, an update on my original query.. 
  32.  
  33. Unless I have overlooked something my present struggles lead me
  34. to suspect that there is a SERIOUS FLAW with the DLL OWL/Container 
  35. class library memory allocation system under Borland C++ 3.1.   
  36.  
  37. I hope I'm wrong..
  38.