Date: Fri, 7 Aug 1998 23:21:59 -0600 From: Nate Williams <nate@mt.sri.com> To: Wes Peters <wes@softweyr.com> Cc: Nate Williams <nate@mt.sri.com>, Terry Lambert <tlambert@primenet.com>, jdp@polstra.com, chat@FreeBSD.ORG Subject: Re: Heads up on LFS Message-ID: <199808080521.XAA23668@mt.sri.com> In-Reply-To: <35CBD340.86A928C9@softweyr.com> References: <199808071637.KAA19141@mt.sri.com> <199808072218.PAA01251@usr02.primenet.com> <199808072250.QAA22022@mt.sri.com> <35CBD340.86A928C9@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > *Right* And you've never written a program that leaked memory, nor had > > *any* errors due to malloc/free problems, or dealt with them. > > > > If you can say that every program you ever written that used dynamic > > memory has never had problems, then I don't believe you. ... > I have written *several* programs, systems really, that don't leak > memory. I never said it couldn't be done, I said that it isn't *always* done, and it takes alot of time/effort to do right. > We prove this by running them at 95+% usage for 30 days at a time and > monitor the memory usage. Since these are embedded systems, if they leak, > they eventually crash. It is *not* true that every C or C++ program > leaks memory, as each of these systems was implemented in C and/or C++ > (running on VxWorks). I'm sorry if I made the impression that it's impossile to right a correct program. However, it is difficult to do so, so *very few* programs behave 100% correctly, especially so when you use C++, which makes it really easy to leak memory if you use some of the more esoteric features. Basically, you're helping make my point. It's *hard* to write 100% correct highly dynamic *real* systems using malloc/free. However, it's *MUCH EASIER* to write 100% correct highly dynamic programs using a GC system. The same problems plague both of them in embedded systems (wanting a resource and it not there to get), but the GC version has an advantage of being eaiser to get right w/out trying real hard, and the C/C++ version has the advantage of being *slightly* better at managing resources if you try *real* hard. If you're willing to work that hard for your performance, why not use hand-coded assembly. It's essentially the same thing. If you need the absolute bare-metal performance, then the only way to get it is to get down to the bare-metal. The choice of memory allocations is so far up on the list of things to worry about that it's simply not worth worrying (or for that matter arguing) about. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808080521.XAA23668>