manual memory management

[Rob T]

On Wednesday, 9 January 2013 at 11:24:32 UTC, Jonathan M Davis 
wrote:
> Walter wasn't arguing that there wasn't a place for manual 
> memory management.
> He was arguing that you can't guarantee memory safety if you're 
> using manual
> memory management - hence why malloc and free are @system. 
> @system code is not
> memory safe like @safe code is, but it still very much has it's 
> place.
>
> - Jonathan M Davis

You cannot guarantee memory safety with a GC either, depending on 
the definition of "memory safety".

For example, you can still access deallocated memory by mistake, 
run out of memory due to accumulating persistent pointers left 
around by mistake, or free memory that was not supposed to be 
freed by mistake. The GC implementation may fail due to bugs, 
deallocating live memory or failing to deallocate inactive memory.

The only thing a GC can do for you, is free up the programmer 
from the tedium of managing memory. It also allows constructs 
that otherwise would be very difficult or impractical to 
implement. The effect can be very positive, but there are no 
guarantees of memory safety.

I also doubt that a "one size fits" all approach to garbage 
collection will ever satisfy everyone. What's needed is the 
ability to both manage memory manually and automatically (D 
allows this which is good), but also allow for the automated 
methods to be easily replaced (plug-ins come to mind), and if 
possible allow sections of code to be managed by completely 
different garbage collector implementations that are designed to 
serve different purposes (this may or may not be practical to do).

--rt