home *** CD-ROM | disk | FTP | other *** search
- 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
- From: stigj@dhhalden.no (STIG JORGENSEN)
- Newsgroups: comp.sys.atari.st.tech
- Subject: Re: Malloc (Was: Sending objc_draw to a buffer)
- Message-ID: <stigj.22.726591656@dhhalden.no>
- Date: 9 Jan 93 15:00:56 GMT
- References: <2b3de6cf@p15.f202.n281.z2.fidonet> <1993Jan3.035343.15539@netcom.com>
- Sender: news@dhhalden.no (Network News User)
- Organization: Ostfold College
- Lines: 45
- Nntp-Posting-Host: pc128
-
- In article <1993Jan3.035343.15539@netcom.com> ersmith@netcom.com (Eric R. Smith) writes:
- >From: ersmith@netcom.com (Eric R. Smith)
- >Subject: Malloc (Was: Sending objc_draw to a buffer)
- >Date: Sun, 3 Jan 1993 03:53:43 GMT
- >In article <2b3de6cf@p15.f202.n281.z2.fidonet> p15.f202.n281.z2.fidonet!Vincent_Partington@nextjk.wlink.nl writes:
- >>In a message of <Fri 25 Dec 92 20:52>, Conan Ford (2:281/202.0) writes:
- >>
- >> CF> one and set up some pointers to each "page". This is because of
- >> CF> the problems GEMDOS has when you use MALLOC for more than 20
- >> CF> seperate buffers (e.g. system crash :-) ).
- >> CF> (Though you probably know :-) )
- >>
- >>Let's just hope this BUG has been fixed in MiNT. There it would REALLY be
- >>annoying. It's annoying now, you have to allocate memory and manage it
- >>yourself but of course TOS should do that for you.
- >
- >The 20 Malloc per program limit was removed a long time ago (certainly
- >it was gone in TOS 1.4). And, of course, MiNT has no such limit.
- >
- >Managing memory "yourself" (i.e. by asking the operating system for
- >large blocks of memory, and having your own malloc() function split
- >those large blocks up for your program) is still a good idea, for 2
- >reasons:
- >
- >(1) it's faster (entering the OS is always going to add overhead), and
- >(2) it may save memory: on a virtual memory or memory protected system,
- > the OS must manage memory in pages; so even if you ask for 1 byte,
- > an entire page (4K or 8K) must be used by the OS for your block
- > of memory.
- >
- >Most libraries' malloc() functions will handle everything automatically,
- >allocating memory in large chunks (4K or 8K or even 32K) from the OS
- >and then splitting those chunks up as necessary. See for example the
- >MiNT or GNU C library malloc()/sbrk() code. All the programmer has to
- >remember is to use the standard C malloc()/free() functions instead
- >of the Atari specific Malloc()/Mfree() functions.
- >
- >Eric Smith ersmith@netcom.com ersmith@atari.uucp
- >
-
- I was just wondering if Pure C has this built in in its library. I am
- writing a little program that checks if there are any duplicates on the
- harddisk. Here I use a linked list and make a Malloc() call for every member
- of the list. There hasn't been any proglems yet. Do you know if Pure Chas
- this built in?
-