home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / atari / st / tech / 6561 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  2.8 KB

  1. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!usc!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!aun.uninett.no!nuug!dhhalden.no!pc128.dhhalden.no!stigj
  2. From: stigj@dhhalden.no (STIG JORGENSEN)
  3. Newsgroups: comp.sys.atari.st.tech
  4. Subject: Re: Malloc (Was: Sending objc_draw to a buffer)
  5. Message-ID: <stigj.22.726591656@dhhalden.no>
  6. Date: 9 Jan 93 15:00:56 GMT
  7. References: <2b3de6cf@p15.f202.n281.z2.fidonet> <1993Jan3.035343.15539@netcom.com>
  8. Sender: news@dhhalden.no (Network News User)
  9. Organization: Ostfold College
  10. Lines: 45
  11. Nntp-Posting-Host: pc128
  12.  
  13. In article <1993Jan3.035343.15539@netcom.com> ersmith@netcom.com (Eric R. Smith) writes:
  14. >From: ersmith@netcom.com (Eric R. Smith)
  15. >Subject: Malloc (Was: Sending objc_draw to a buffer)
  16. >Date: Sun, 3 Jan 1993 03:53:43 GMT
  17. >In article <2b3de6cf@p15.f202.n281.z2.fidonet> p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl writes:
  18. >>In a message of <Fri 25 Dec 92 20:52>, Conan Ford (2:281/202.0) writes:
  19. >>
  20. >> CF>  one and set up some pointers to each "page".  This is because of
  21. >> CF>  the problems GEMDOS has when you use MALLOC for more than 20
  22. >> CF>  seperate buffers (e.g. system crash :-)  ).
  23. >> CF>  (Though you probably know :-)   )
  24. >>
  25. >>Let's just hope this BUG has been fixed in MiNT. There it would REALLY be
  26. >>annoying. It's annoying now, you have to allocate memory and manage it
  27. >>yourself but of course TOS should do that for you.
  28. >
  29. >The 20 Malloc per program limit was removed a long time ago (certainly
  30. >it was gone in TOS 1.4). And, of course, MiNT has no such limit.
  31. >
  32. >Managing memory "yourself" (i.e. by asking the operating system for
  33. >large blocks of memory, and having your own malloc() function split
  34. >those large blocks up for your program) is still a good idea, for 2
  35. >reasons:
  36. >
  37. >(1) it's faster (entering the OS is always going to add overhead), and
  38. >(2) it may save memory: on a virtual memory or memory protected system,
  39. >    the OS must manage memory in pages; so even if you ask for 1 byte,
  40. >    an entire page (4K or 8K) must be used by the OS for your block
  41. >    of memory.
  42. >
  43. >Most libraries' malloc() functions will handle everything automatically,
  44. >allocating memory in large chunks (4K or 8K or even 32K) from the OS
  45. >and then splitting those chunks up as necessary. See for example the
  46. >MiNT or GNU C library malloc()/sbrk() code. All the programmer has to
  47. >remember is to use the standard C malloc()/free() functions instead
  48. >of the Atari specific Malloc()/Mfree() functions.
  49. >
  50. >Eric Smith    ersmith@netcom.com    ersmith@atari.uucp
  51. >
  52.  
  53. I was just wondering if Pure C has this built in in its library. I am 
  54. writing a little program that checks if there are any duplicates on the 
  55. harddisk. Here I use a linked list and make a Malloc() call for every member 
  56. of the list. There hasn't been any proglems yet. Do you know if Pure Chas 
  57. this built in?
  58.