manual memory management
Walter Bright
newshound2 at digitalmars.com
Tue Jan 8 14:19:50 PST 2013
On 1/7/2013 3:11 PM, H. S. Teoh wrote:
> I think much of the aversion to GCs is misplaced. I used to be very
> aversive of GCs as well, so I totally understand where you're coming
> from. I used to believe that GCs are for lazy programmers who can't be
> bothered to think through their code and how to manage memory properly,
> and that therefore GCs encourage sloppy coding. But then, after having
> used D extensively for my personal projects, I discovered to my surprise
> that having a GC actually *improved* the quality of my code -- it's much
> more readable because I don't have to keep fiddling with pointers and
> ownership (or worse, reference counts), and I can actually focus on how
> to make the algorithms better. Not to mention the countless frustrating
> hours spent chasing pointer bugs and memory leaks are all gone -- 'cos I
> don't have to use pointers directly anymore.
I had the same experience. For the first half of my programming career, I
regarded GC as a crutch for loser programmers. After working on Symantec's Java
compiler, and later implementing Javascript, I discovered that I was quite wrong
about that, pretty much the same as you.
One thing I'd add is that a GC is *required* if you want to have a language that
guarantees memory safety, which D aims to do. There's an inescapable reason why
manual memory management in D is only possible in @system code.
Interestingly, carefully written code using a GC can be *faster* than manual
memory management, for a number of rather subtle reasons.
More information about the Digitalmars-d
mailing list