What errors are saved by brevity? [closed] - c++

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
"C++ Primer" (5th edition) suggests on page 149 that a brief code can be less error-prone than a longer alternative. It brings the following line of code to serve as an example:
cout << *iter++ << endl;
It claims that the above line is less error-prone than the alternative:
cout << *iter << endl;
++iter;
To me, even though the meaning of *iter++ is clear, this expression still requires a non-zero mental effort to parse and so the second version is more readable. So, I want to understand: what is more error-prone about the second version?

Answer 1

I also do not agree with the author.
Usually each code snippet has a tendency to be changed in the future.
For example this statement
cout << *iter++ << endl;
can be changed the following way
cout << *iter++ << ... << SomeFunction( *iter ) << endl;
In this case the code will have undefined behaviour because the order of evaluation of function arguments is unspecified.
So in my opinion this code snippet
cout << *iter << endl;
++iter;
is less error-prone.:)
Introducing side-effects in a code snippet does not make it less error-prone.
Moreover in the code snippet you showed there is no logical relation between the increment of the iterator and outputting its value.
cout << *iter++ << endl;
So it is unclear why the iterator is incremented in this statement.
Separating this statement into two statements makes the code snippet more clear because it seems that the incrementing is related to some other parts of the code.
The brevity makes the code more expressive. But it does not mean that it necessarily makes also the code less error-prone.:)

Answer 2

The thing is, when you have your function containing a few lines on code, each one of them is treated as a "step" to achieve some goal. When you read such a function you read each line and think what it does and why. In your example,
cout << *iter << endl;
++iter;
logically could be one step: "when iterating over the container, write each element to cout". It's because when you forget either of these lines, the whole step is incorrect. Of course, this very example is not particularly great, because it's not hard to come up with a code, in which the two lines are two different logic steps. However, I assume the author meant, that by writing
cout << *iter++ << endl;
you protect yourself from forgetting one part of a logic step as well as you make a signal for a reader that this is one logic step.

Answer 3

I can think about the lines being reordered for some reason (maybe they became separated by some other code and it was later modified), or an if/for/while being added, either without braces or with them wrongly placed:
++iter;
cout << *iter << endl;
if (some_condition)
cout << *iter << endl;
++iter;
while (something_happens)
{
cout << *iter << endl;
}
++iter;
In this small example, the bugs are quite obvious, but that may not be the case when you have a lot more lines.
(And yes, I know the indentation in the 2nd and 3rd examples should be corrected, but sadly I've seen lots of examples like these).

Answer 4

I couldn't disagree with the author more.
The expression *iter++ does two different things to iter - it dereferences it and increments it. Yes, the order is defined, but understanding the results of two actions on a single variable in a single expression requires inherently more brainpower than something which has only one effect on a single variable.
One of the most reliable ways to increase errors from a developer is to unnecessarily increase the brainpower needed to understand what their code actually does.
The virtue of breaking the effects into two distinct statements is that it is easier to understand.
The other phenomenon is that programmers who are taught to include two effects on a single variable in a single statement are more likely to craft expressions with even more effects on some poor variable. Apart from making their code even less comprehensible, it also increases the likelihood of undefined behaviour (since any expression that modifies any variable more than once in a single expression has undefined behaviour).

Answer 5

It might be worth comparing to similar constructs in other languages.
In python, to iterate over a sequence, we use a generator. There is essentially only one operation you can do with a generator: call next which obtains an element and advance the generator. Iteration, when done manually, is done by repeatedly calling next to get the terms of the sequence until it raises StopIteration to signal the end of the sequence.
In java, to iterate over a sequence, we us an Iterator. There is essentially only one operation you can do with an iterator: call next which obtains an element and advances the iterator. Iteration, when done manually, is done by repeatedly calling next to get the terms of the sequence until hasNext returns false to signal the end of the sequence.
In C/C++... we often want to get an element and advance through the sequence. It has been long established (AFAIK before C++ even existed) that this operation is *p++.
The only reason we are even contemplating the idea of breaking this into two steps -- one step being to get the current element and the other step being to advance to the next term -- is an artifact of an implementation detail.
In a situation where one is truly thinking of these two steps as being separate, independent things, then it would be best to keep them as separate expressions.
But it is relatively well established that that is not how people are thinking -- people are thinking in terms of "getting an element and advancing the iterator". Iteration, when done manually, is done by repeatedly invoking *iter++ to get the terms of the sequence, until iter == end_iter returns true to signify the end of the sequence.
When thinking this way, splitting the one conceptual step into two syntactically separate elements (*iter and ++iter) is more error prone than keeping it as a single step.

Answer 6

Not a good example, because you shouldn't use while without braces, but it could lead to errors like this: In this case you would have an infinite loop when adding the while.
while (*iter)
cout << *iter << endl;
++iter;
I think it is a bad example! Much better would be an example, where you have multiple dependent steps. Then someone copies some steps to another function, but misses some lines, which don't look they are semantically needed.