Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Andrew Koenig

Dr. Dobb's Bloggers

Addresses and Nodes: Two Ways To Get Around

August 29, 2013

Last week, I noted that programs that avoid address arithmetic can also avoid moving data. The reason is that it is only arithmetic that really cares about where in memory an object is; in other circumstances, having a pointer to that memory is enough. Therefore, if we refer to memory only through a pointer to that memory, we don't actually care about the contents of that pointer. In particular, avoiding address arithmetic gives us a completely different way of thinking of one object as being "next to" another — instead of the two objects occupying adjacent memory locations, one of them is located in a place that is easy to reach from the other by following a pointer.

This alternative notion of "next to" is what distinguishes random-access iterators from other iterator categories in C++. Without using random-access iterators, there is no way to navigate instantly between two arbitrary places in a container. Instead, one must move from one element to the one next to it, then to the one next to that, and so on. On the other hand, avoiding address arithmetic also makes the notion of position in a sequence much more flexible.

As an example of this flexibility, consider the insert member of C++ standard containers. If c is a container, p is an iterator that refers to a position in that container, and x is a value that can stand as an element of that container, then

               c.insert(p, x);

creates a new element in c that contains a copy of x. This element is inserted into the container ahead of the position p. If the container uses address arithmetic to determine its elements' positions, then the newly created element must take the place of the element to which p formerly referred (assuming that p is not an off-the-end iterator). That element must be moved to the successor position of its old location, and all the elements after it must similarly be shifted. If, on the other hand, the container does not use address arithmetic, then the library can generally arrange for the new element to appear at the right place in sequence merely by manipulating pointers.

A container that uses pointers to locate its elements is sometimes called a node-based container. The word node normally carries the idea that the various nodes that constitute such a data structure are independent of each other. In particular, they can be inserted, deleted, and reconnected without ever moving the nodes themselves or changing their contents apart from the parts of the nodes that might be used to locate other nodes. We can think of nodes, connected by pointers, as an alternative to arrays, the elements of which are connected by the numbers that constitute their addresses.

These alternatives — nodes and arrays — go back to the dawn of programming languages. Four of the earliest programming languages were Cobol, Fortran, Algol, and Lisp. Cobol, Fortran, and Algol all used data structures based on arrays; Lisp used data structures based on nodes that were connected by pointers.

Notice that of these four early languages, three were array-based. To varying degrees, all three of them were also based on a desire to make computer hardware facilities easier for people to use. Lisp's philosophy was distinctly different: Its purpose was to use a computer to implement a particular mathematical abstraction. As a result, the people who designed Lisp didn't care nearly as much about how closely their language mirrored an actual computer's behavior.

Next week, I'm going to discuss some fundamental ways in which Lisp differed from the other three languages as a result of this difference in philosophy, after which I will trace some of these differences all the way to present-day languages.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.