clipka wrote:
> Um... what's wrong with malloc() and free()??

It exposes the internals of the memory allocations to the caller. And it's 
difficult to manage if you don't have at least destructors. And it can be 
inefficient if you do it a lot. And sometimes you need certain kinds of 
memory (like DMA-accessible memory) so you wind up with multiple kinds of 
malloc and free.

But mostly because it exposes the internals of the memory allocations to the 
caller, which is usually less of a problem until you combine it with the 
other problems, like threading.

Say you're generating some audio by reading hardware-compressed samples off 
a microphone, then shipping it out over a connection that's packetized and 
interleaved with other data (RTP, for example).  You don't know how big the 
data you're reading is, and you don't know how big the data you're writing 
is. One thread is reading from the microphone and filling buffers. One is 
coordinating. One is writing the buffers to the socket. Who is responsible 
for allocating buffers? Who is responsible for freeing them? Especially 
given that the buffers you're writing might not be the right size for the 
buffers you're reading.

Sure, you can use malloc and free. But I've seen maybe 5% of the programs 
I've worked with *not* layer other memory management stuff on top, and each 
"on top" is incompatible with the other "on top"s. You can't read a buffer 
from John's DVD reader, feed it into a Python data structure, then take that 
and stuff it out to a MPEG decoder hardware interface without copying it 
three times. Heck, Qt is written in C++ and it doesn't make use of any of 
the STL *or* C strings. You know how you print out the URL stored in a 
"QURL" object?  myQurl.toAscii().constData() gives you an actual char* (or 
something like that). Because Qt didn't like STL for some reason.

Everyone builds up big abstractions to help. If you have to do it yourself, 
you're going to build abstractions suited to the program you're writing. If 
you don't have to do it yourself, you have to haul around the whole library 
from someone else and keep up with *their* changes.  I think this is a big 
part of what the .NET stuff is trying to solve with all the "component" part 
of the framework.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message