Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> From: nmeyers at javalinux.net > To: Glenn Burkhardt <gbburkhardt at aaahawk.com> > Cc: BLU Discussion List <discuss at blu.org> > Subject: Re: C++ use of Malloc/Realloc and Free > > On Mon, Jun 23, 2003 at 05:48:14PM -0400, Glenn Burkhardt wrote: >> > On Sun, Jun 22, 2003 at 04:15:57PM -0400, Jerry Feldman wrote: >> > > > So I agree with you that using malloc/free/realloc can be quite >> > > > dangerous, there are some occasional times where the risks >> > > > outweigh the danger. >> > > Yes, you are quite correct. The bottom line is that the programmer >> > > must understand the issues. >> > >> > Ok, I'll bite. What are the issues? I've not done much C++ >> > programming, but I'm curious... >> > >> > - -- >> > Derek D. Martin >> >> I don't think it's very complicated, but as always, one needs to be >> aware of what happens. Just make sure that if you allocate memory >> within a class, that the destructor for the class frees it. Sort of >> like making sure that memory allocated by a function is released >> before it returns. If pointers to allocated memory are passed around >> between classes, the same problems exist as for passing pointers to >> allocated memory between C functions. One doesn't want it freed in a >> destructor and then used, or have it left dangling. > > Constructors and destructors can do anything from manage memory to > launch missiles - they are whatever the programmer wants to be executed > automatically when objects go into and out of existence (either in the > heap or on the stack). So, in the general case, it *can* be very > complicated. Using malloc/realloc/free bypasses that mechanism and can > completely change the function of the object. That's the issue: you > have to understand what functionality you're short-circuiting. > > Nathan Meyers > nmeyers at javalinux.net I have been lurking on this set of threads and I have a few notes. malloc et. al. are also very poor for performance. The memory heap is often times a point of contention for multi-threaded programs. Some of the tricks are to use devices like "alloca" (under Windows this is _alloca) which allocates memory off the stack which does not need to be explicitly freed, it goes away when you exit the function. Another problem with all dynamic memory allocation strategies is heap fragmentation. In a standard use app, this isn't much of a problem, but in a long running server, using the heap with a lot of odd sized objects can cause little bits of allocated memory to slowly fill up the process space. Imagine this scenario: You allocate a 2K chunk of memory for a buffer, allocate 1K for an persistent object, free your buffer, allocate another object that is 1K. You just successfully wasted about 1K of memory space in your system. As all allocation systems must use some memory to manage memory blocks, the 1K left over isn't really big enough to satisfy a 1K allocation request. Over time, if this continues, your process space will grow. Eventually, you will fill all available memory and swap, untill, ultimately, you are killed by the user or the OS. What is funny about this mode of death, is that the system says you are only using a small amount of memory, and have lots of free space, but your process is sucking up tons of system memory and swap. If you allocated your 2K buffer with alloca, it would be just as flexable, but would have come off the stack, and you would not have fragmented your heap. I don't subscribe to the notion that APIs are "good" or "bad," it is just how you use them. C/C++ is a VERY powerful toolset, but don't be surprised when it allows you to do something bad. If you take the time to learn the mechnics of the compiler, i.e. how it works, so much so that it is obvious, you will never fear things like pointers, malloc, and casts.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |