Channels ▼
RSS

C/C++

The Need For Immutability


For many programmers, the emergence of data immutability as a desirable feature in programming languages is a curious development. Immutability — the capacity to create variables whose initial value cannot be changed — is suddenly the mode.

When the programming world was dominated by C and C++, most instructional materials barely touched on immutability. The entire conversation recognized the occasional need for constants and proscribed the use of a magic number, such as 3.14159. Eventually, a constant, PI, was suggested to help the good folks who'd have to maintain the code at some time in the future.

Except for the plaintive cry of academics whose fondness for functional languages was thoroughly ignored, the above was pretty much all you heard about data immutability. This situation changed with the advent of Java in 1995: The language implementation hid immutability behind the scenes. Strings, as well as other fundamental data types, were constants, rather than variables. This design was in part a reaction to the great difficulty of managing strings in C and C++. Because those languages treat strings simply as null-terminated arrays of characters, C strings are infinitely pliable, plastic entities that anyone with a copy can modify. Java, in counterpoint, views strings as their own fundamental and immutable data type.

Java expanded immutability in the release of Java 2 by adding immutable collections. These collections are quite useful in regular serial programming. For example, a getter that returns a collection should in most cases return an immutable collection. This step enforces data hiding and encapsulation: Objects that don't own the collection cannot change its values. Immutability makes data items ideal for sharing between threads. It enables two threads to access a string simultaneously without the usual elaborate locking mechanisms.

With the wide adoption of x86 multicore processors, all programs have the possibility of useful parallelization, and so immutability is moving inexorably to the fore. New languages, such as Scala, provide for it expressly (a one-letter change in a variable declaration creates an immutable constant). Languages derived from the functional world (Erlang and Clojure, for example) embrace immutability even further, making it the default behavior for variables. Languages, such as Groovy, that did not have immutability as a definable quality, first added it as an adjunct (in Groovy's case, as an annotation), and then as an integrated part of the language. C and C++ are laggards here — const correctness being the partial and somewhat cumbersome mechanism.

For developers not interested in multithreading, immutability still has a role to play as I've mentioned. But the full breadth of opportunity is much greater. It's safe to say that wherever possible, data items should be declared as immutable. The first benefit is performance. Compilers are very good at optimizing code when they know a data item won't change value.

Even if your code is fast enough, immutability has value. By specifying that an object is immutable, you can catch defects that might have been difficult to detect. For example, the long held practice of marking parameters to methods as final prevents you from mistakenly modifying a value that will be wiped away when the method returns. However, even within methods, there are many times when an object is returned from a function only for purposes of calling one of its methods. It too can be marked immutable. This prevents mechanical errors and provides greater readability. (As with all guidelines, this has to be tempered by the pragmatic realities. Code clutter, especially in languages that don't have simple immutability keywords, can be a drawback that more than offsets the readability benefits.)

My belief is that data immutability will become much more pervasive part of all programming languages — fully integrated at the syntactical and semantic levels. This, I expect, will presage the wider penetration of parallel programming into general-purpose languages.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy


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.
 

Video