Arnold Robbins discusses dynamically allocated memory, focusing exclusively on the user-level view of the process and its memory.
User-Level Memory Management in Linux Programming
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
That article was pants….
Any discussion of dynamic memory allocation in on linux these days should also cover ways to reduce or detect errors and leaks. Where was the mention of Electric Fence, NJAMD and Valgrind?
There’s nothing there worth reading…
“alloca … doesn’t exist on non-Unix systems.” Not quite. OpenVMS has it too.
I’d like to see Figure 3.1 – it is a hotspot – the mouse pointer changes – but it does not enlarge or do anything when I click on it – on SuSE 9.1 or W2K.
is it at all worthwhile to implement your own VM system for shared memory? if you’ve got a large collection of shared mem objects i can see there being some penalty or limit to how many objects you can share. or is there really no reason not to share a thousand or so individual memory objects?
does it just boil down to how much locking you have to do? i can see that you’d need the same semaphore structure whether you’re just using a lot of objects or whether there’s some VM subsystem. I can see the possibility of there being no real advantage.
same # of locks = same performance?
Myren
In 2004 it is irresponsible to write user applications without automatic memory management (such as garbage collectors).
C is meant for writing operating systems and drivers, not applications.
That’s simply not true. Many useful applications can be securely writen without the fear of memory leaks or string overflows. Just because you’re overly paranoid and/or bought into MS’ or Sun’s “automatic memory” hype, hardly validates it. Besides, these days, there are many tools to help you figure out if you even have memory leaks. In C++, while there are perhaps some more gotcha’s lurking, a lot of memory management issues have been resolved at the class level. Lastly, let’s not forget that there are automatic collectors available for both C and C++ developers. Either way, only a fool is going to rule out C or C++ for memory management reasons alone. Pick the best/proper tool for the job.
Depending on the complexity of the project and associated code, memory mnagement may not even be an issue for an application.
My point? Speaking in such absolutes is *almost* always wrong.
I read this with, I am not sure if it is disbelief or humour. “C is meant for writing operating systems and drivers, not applications.” <scarcasm mode=on>Wow may be I should tell our customers that their apps will not work 24/7 unlike their efficent and memory safe VM/GC ones do.</scarcasm>
C is for building anything I need. If you can’t run with the big dogs stay under the porch.
Any suggestions?
ok, great — show me one single web-safe servlet written in C.
A C memory manager won’t guarantee the type safety of :
arr[idx]
Likewise there’s no guarantee that you get something meaninful from:
(some_type*) x
oops, meaningful
Please define and I am sure we can.
See the flight reservations problem:
http://asp0.ccs.neu.edu/home/dsilva/
“ok, great — show me one single web-safe servlet written in C.”
Ok, great — show me one single console video game written in something else than C or C++.
Here’s a 3D game written in 2000 in ocaml, and it ran at full speed on a pentium:
http://graphics.stanford.edu/courses/cs248-videogame-competition/cs…
The problem with consoles is porting a platform’s VM to a closed architecture.
I was under the impression that servlets were java, as in java.sun.com/products/servlet/, but still I’m sure you wouldn’t be asking “show me one single Java program written in C.”
Anyway, I recently wrote an AVL tree implementation in Java, and it was really very bad, without garbage collection it would have been unworkable. This doesn’t mean though that AVL trees must be written in managed languages, apparently the linux kernel even implements them internally (according to msu.edu/user/pfaffben/avl/ anyway) so I’m fairly sure it’s possible to do it “responsibly.”
And why am I bothering to reply to a comment like that? Sorry, I’ll stop.
> The problem with consoles is porting a platform’s VM to a closed architecture.
No, the problem with consoles is that memory is limited, there is no virtual memory. All garbage collecting languages are therefore completely useless for writing the big core engines of console games. C/C++ remains the only practical choice. Lisp and Python have been successfully used in a limited fashion for scripting game events though.
Also, console platforms aren’t as closed as you think. If you’re an official game developer, you have full control and can in theory port anything you want to them.
I just don’t seem to understand why they lump C++ with C when it comes to memory leaking. C++ does provide a means to keep memory leaks from happing.
Are you ready for it?
Proper use of the destructor!!! That is one of the reasons it exists. To allow for cleanup. It isn’t hard to use. I have been developing apps using C++ for seven years now without a single leak in the field, and please don’t think that I think I am the “cats meow”. I am not. Hell, I was a EE for a few years before I switched to software.
Just because people can get lazy doesn’t mean that all of us need managed code. I say this with a year and some under .NET.
The Java Native Interface gives me full unbridled access to that rich java library including the servlet api from C.