Xref: utzoo comp.sys.mac.programmer:4592 comp.lang.c:16379
Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!ima!cfisun!lakart!fgz
From: fgz@lakart.UUCP (Federico Genoese-Zerbi)
Newsgroups: comp.sys.mac.programmer,comp.lang.c
Subject: Re: Mac LightSpeed C question (elementary)
Message-ID: <432@lakart.UUCP>
Date: 17 Feb 89 14:42:51 GMT
References: <11781@haddock.ima.isc.com>
Organization: Lakart Corporation, Newton, MA
Lines: 32

From article <11781@haddock.ima.isc.com>, by karl@haddock.ima.isc.com (Karl Heuer):
> In article <423@lakart.UUCP> fgz@lakart.UUCP (Federico Genoese-Zerbi) writes:
>>From article <1158@naucse.UUCP>, by rrw@naucse.UUCP (Robert Wier):
> The library routines malloc() and free() are the usual way of doing this.
> 
> Is there any good reason to use these rather than the standard interface?  If
> the only answer is that it avoids one function-call overhead, then I suggest
> that (a) portability is important, even if you have no current plans to port
> this program, and (b) malloc() and free() ought to be implemented as macros on
> that system.
Your points are well taken.  Consider the following issues however:
   (1)  Most macintosh programmers I know (myself included) are very used to
	looking at Macintosh code.  NewPtr() and DisposPtr() believe it or
	not, make for more readable code.
   (2)  For the purpose of portability, NewPtr() and DisposPtr() replacement
	are the least of your worries.  In the worst case you can just macro
	them out.  The toughest task is writing code that does what things
	like Get/WaitNextEvent(), FindWindow(), ctl manager stuff, etc.  I
	ported a mac application to a Sun workstation under X-Windows, and
	it was a hairy mess to deal with.

A final note.....If  you are going to be doing a lot of memory allocating/
deallocating, you should use NewHandle() and DisposHandle(), some calls
to MoreMasters() at the beginning of your code (There is a Technical Note
outlining how to determine how many to use) and HLock() and HUnlock() when
dereferencing/done dereferencing.  Your memory will thank you for it after
a while (i.e. it won't get all fragmented).

> Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint

Cheers,
Federico