Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!aurora!labrea!decwrl!decvax!tektronix!reed!psu-cs!smethers
From: smethers@psu-cs.UUCP (Paul Smethers)
Newsgroups: comp.sys.mac
Subject: Re: LSC, Mac limitations?
Message-ID: <501@psu-cs.UUCP>
Date: 21 Feb 88 08:07:56 GMT
References: <1161@hao.ucar.edu> <981@cadre.dsl.PITTSBURGH.EDU> <8158@eddie.MIT.EDU>
Reply-To: smethers@psu-cs.UUCP (Paul Smethers)
Organization: SmethersBarnes
Lines: 35

In article <8158@eddie.MIT.EDU> zrm@eddie.MIT.EDU (Zigurd R. Mednieks) writes:
>
>Fer gosh sakes, use the Mac Toolbox memory managment. Especially if
>you are managing big chunks of memory, and have dynamic requirements
>through the course of running the program. The Mac Memory Manager has
>far more powerful and efficient ways of handling memory allocation and
>compaction than the standard Unix library has.
I agree that the Mac Memory Manager is probably the best way to go when
implementing programs on the Macintosh, but by using it you restrict your
portability to other machines.  Even if I never plan on porting an application,
I am always very weary of writing code that may later restrict it.  If you
don't think that malloc is done right, then use macros that hide what you
are doing, and redefine the macros on other computers.

>................. Furthermore, since the Toolbox is the same
>everywhere, and the Unix libraries are implemented separately in every
>Mac development environment that has them, you are better off sticking
>to the Toolbox if you ever change your mind about compilers (or
>languages, for that matter).
Again, you are making the assumption that a program will never work on a
unix windowing system (such as a Sun), or an IBM.  All computers are now
converging to windowing systems, and even though you write for the Mac
now, you never know when you need the portability.  The windowing portability
is not a easy problem, but the memory portability is almost free because
of the standards with unix libraries (malloc type routines).  The same
goes for file i/o (printf).

One of the reasons we write in 'C' instead of Assembly is because
we want portability that Assembly doesn't give us (sure there are
other reasons, but this is one of them).  Pascal has too many extensions
and dialects, but K&R 'C' is pretty portable if you follow good coding
practices.

Paul Smethers
SmethersBarnes