Channels ▼

Andrew Koenig

Dr. Dobb's Bloggers

The auto Controversy

August 03, 2011

When Barbara and I wrote our first DDJ article about C++0x , we didn't think it would be controversial. Nevertheless, several readers have spoken out about auto. Rather than responding to those comments individually, I thought I'd explain my thinking in more detail.

I think it is fair to summarize the criticism of auto as "it makes programs harder to read." One reader added:

… the convenience offered up by auto is really just an insidious trap that will lead to writing less transparent code. Even if auto enables you to, say, effectively capture return values without needing to know the specific type returned by a method, then what? You'll still need to know the type returned and its methods, properties, etc. to use it from that point forward…

The notion that a language feature, by itself, "makes programs harder to read" is, in my opinion, an insidious trap — for two reasons, and maybe more.

The first reason is that language features don't make programs harder or easier to read; programmers do. So if what you're really trying to say that it's impossible to use a particular feature without making programs harder to read — you're making a pretty strong claim. Such claims require similarly strong proof to back them up. I think that not only is such proof hard to come by, but that I can find counterexamples. In particular, I intend to show some examples of auto that — at least to me — make the program easier to read, not harder.

The second reason I think that "makes programs harder to read" is an insidious trap is that it states a subjective judgment in objective terms. I think it would be better to say "I find programs that use auto harder to read than programs that don't," because then you're making a statement not only about the programs but about yourself. This distinction is important because people often mistake unfamiliarity for difficulty. For example, when templates and template libraries started entering C++, Barbara told me that she was skeptical that people would ever learn to program with containers and iterators — that style of programming was just too confusing. These days, it's hard to imagine programming in C++ without them. Once the unfamiliar becomes familiar, people no longer see it as inherently confusing.

To make this discussion more concrete, let's take a look at how we would implement the standard reverse algorithm from scratch:

template<class It> void reverse(It begin, It end)
 {
       while (begin != end) {
            --end;
            if (begin != end) {
                 std::swap(*begin, *end);
                 ++begin;
            }
       }
  }

This implementation checks whether begin is equal to end twice each time through the loop so that it does not have to use a < comparison, which would require It to be a random-access iterator.

Suppose that we really wanted to implement reverse from scratch, in the sense of not using std::swap. How would we write this code? With auto, it's easy:

template<class It> void reverse(It begin, It end)
 {
       while (begin != end) {
            --end;
            if (begin != end) {
                    auto temp = *begin;
                    *begin = *end;
                    *end = temp;
                    ++begin;
                }
           }
 }

How would you do it without auto? I can think of only two ways offhand. One is to introduce an auxiliary template function to take the place of std::swap. The other is to actually figure out the type: Instead of using auto, define temp as

iterator_traits<It>::value_type temp = *begin;

I don't understand why this rewrite is an improvement. Not only is it longer than using auto, it still doesn't tell us what the type of temp actually is! To me, it is worse than using auto in an important respect: When I write

auto temp = *begin;

I know that temp and *begin have the same type. If, however, I write

iterator_traits<It>::value_type temp = *begin;

all I know is that I can convert the type of *begin to the type of *temp. I have to look much more closely to determine that they are actually the same type. In short, I think that this example shows that auto does not always make programs harder to read, even subjectively.

In my next few posts, I will take a look at some more examples.

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