Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!pipex!uunet!mole-end!mat
From: mat@mole-end.matawan.nj.us
Subject: Re: Comparing productivity: LisP against C++ (was Re: Reference Counting)
Message-ID: <1994Dec31.080732.1397@mole-end.matawan.nj.us>
Organization: :
References: <D16Ho3.4BE@lcpd2.SanDiegoCA.NCR.COM> <3e2bj6$43a@network.ucsd.edu>
Date: Sat, 31 Dec 1994 08:07:32 GMT
Lines: 28
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:105383 comp.lang.lisp:16216

In article <3e2bj6$43a@network.ucsd.edu>, mbk@inls1.ucsd.edu (Matt Kennel) writes:
> Stan Friesen (swf@elsegundoca.ncr.com) wrote:
> 
> : Memory leaks are relatively easy to deal with if you use a proper
> : constructor/destructor based resource allocation scheme. In most
> : cases a resource, such as memory, should be allocated in the constructor(s)
> : for a class, and released in the destructor.  Even if it is not possible
> : to put the allocation in the constructors, the destructor should *always*
> : release it.
> 
> Is this an equivalent rule for C:
> 
> 	"Memory leaks are relatively easy to deal with as long as you
> 	 use free() when the data pointed to will no longer be used."
> 
> No kidding.

Don't forget that memory isn't the only `resource' that a program
deals with, nor does not `losing' memory by itself indicate that the
handling of a data structure is correct.

That's why it's important to tie dynamic state of any kind _ultimately_
to the lifetime of something with local or external scope.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
	(Training and consulting in C, C++, UNIX, etc.)
