Free Store and Object Allocation

When you use a type, you usually care about two different things: what you can ask it to do, and how it stores its data internally. Most of the time those two things are tangled together. The type exposes its layout, and the code you write depends on that layout.

An abstract type is built to pull these two things apart. It is designed so that a user can work with it without knowing anything about how it is put together inside. This article introduces that idea, shows how it differs from the more familiar kind of type, and explains the practical consequences that follow from it.

Start by asking a simple question about memory. When the user writes a variable of an abstract type, does that variable contain the object itself? According to the source, it does not. The variable holds a way of reaching the object, and the object holds the representation. The diagram below traces this arrangement from the user's variable down to the hidden layout.

Compare this with the picture for a concrete type. A local variable of a concrete type is handled as a value: the value lives in the scope where it is declared, and the surrounding code understands its layout. An abstract object cannot be handled that way, because its layout is deliberately kept out of view. The variable therefore becomes a handle on the object rather than the object itself.

The familiar kind of type is called a concrete type. Types such as complex and Vector are examples. Their representation is part of their definition: the way the data is laid out is written directly into the type's definition, and users can see it. Because of this, concrete types resemble the built-in types that come with the language.

The key test for telling the two kinds apart is a single question: is the representation part of the type's definition? If the answer is yes, the type is concrete. If the representation has been deliberately removed from the definition as seen by the user, the type is abstract. The table below lines up the two kinds against this test.

The source describes the mechanism for insulation in one short phrase: the design decouples the interface from the representation. These two parts need to be separated clearly before the idea makes sense.

Decoupling means these two parts are kept separate. The user's code is written against the interface alone, and the representation can be chosen or changed without disturbing that code. The diagram shows the user's code reaching the interface, while the representation sits behind it and is never reached directly.

The source develops this with a class called Container, intended as a more abstract version of the Vector type seen earlier. Notice the order of work. The interface is designed first, and at that stage only the interface is fixed. Questions about how the elements are stored come later, and they do not leak into the description of what the user may do.

Decoupling changes what a user is entitled to depend on. Before the representation is hidden, user code can depend on how the data is laid out. After it is hidden, user code can depend only on the operations in the interface. The diagram compares the two situations side by side.

The practical payoff follows directly. Because the user's code relies only on the operations, the internal storage can be replaced without the user having to rewrite anything that depends only on those operations. The user's dependency is on what the type can do, not on how the type stores its data.

Since the representation of an abstract type is unknown to the user, not even its size is known. The language design therefore has to avoid any situation in which the compiler or the user's code needs to know that size in advance. The source draws the consequence clearly: objects of an abstract type must be allocated on the free store and accessed through references or pointers.

This explains the whole arrangement. A variable of an abstract type cannot be a container for the object, because the object's size is not known where the variable is declared. The variable instead holds a reference or pointer, and the object lives on the free store, where it holds the representation.

Hiding the representation has a cost, and the source names it directly: the approach gives up genuine local variables. A local variable is a value that lives in the scope where it is declared and is handled as a value. To keep the representation out of view, the design cannot treat an abstract object as a plain value whose layout the surrounding code understands.

The trade is deliberate. The source accepts these restrictions so that the user can work with the type without seeing its internal layout. Losing the convenience of local variables is the price of the insulation the design provides.