Skip to content

{ Monthly Archives } January 2008

On the Ubiquity of Garbage Collection

As far as I can tell, programming language designers do not seem to be creating non-garbage-collected, general-purpose programming languages anymore. This trend is not restricted to "scripting languages" or languages requiring a run time. Performance-oriented languages designed as potential replacements for C++, such as D and OCaml, are garbage collected, and the forthcoming version of the C++ standard will include features explicitly intended to facilitate use of a garbage collector.

Garbage Collection and Functional Programming

This post is going to be short and sweet, because the point is very simple: If you use a functional programming language (and, if you want to learn to think outside of the Delphi box, you should), then you will be using garbage collection.

Non-Reference-Counted Interfaces

[...] far from solving the problem of conflicting systems of memory management, formal language support for a "non-reference-counted" root interface type in Win32 actually seems to make some of the worse. My conclusion is that the present state of the Delphi language is a better option than this proposed change.

Garbage Collection As Unified Memory Management

This is the first of what may become a small series of posts on advantages of garbage collection. Garbage collection is often contrasted with "manual" memory management, as though any application which doesn’t use garbage collection frees all allocations with an explicit call to Free. But that isn’t true at all. In fact, Delphi has several different methods of memory management, depending upon what you’re doing.

Bad Behavior has blocked 1846 access attempts in the last 7 days.

Close