Disk cache, holding the program images in memory in case you want to start them again, and so on. Just because memory is used doesn't mean the OS can't make it available for programs.
Disk cache, holding the program images in memory in case you want to start them again, and so on. Just because memory is used doesn't mean the OS can't make it available for programs.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Windows likes to hog memory itself for caches and stuff and other things, of course.
On Linux, the only resources your program can "hog" after it terminates are disk space (obviously) and SysV shared memory regions. If you create shm regions and don't destroy them before exiting, those regions will stick around.
EVERYTHING else is always released back to the OS.
You also have the remote possibility of triggering a kernel bug and crashing a box, but given that these machines reboot so rarely, I suspect the kernels are pretty solid.
If you are utterly paranoid, you could run everything inside User Mode Linux.
Programs running under gdb don't execute any differently than normal. Running under the debugger doesn't make anything safer, really. The debugger is just a process which watches and manipulates another process. It doesn't even slow it down.
There's nothing stopping you from using Boost. You don't have to install it in /usr/local...As for shared_ptr, it's a boost object, and I can't install it since I don't have root privileges.
Anyway. Especially on Linux there's really nothing to fear. Write code!