Why is while's condition outside the do while scope

Question

More often than not we need loops like this

do
{
     Type value(GetCurrentValue());
     Process(value);
}while(condition(value));

Unfortunately this will not compile, because value's scope ends at }. Which means that I will have to declare it outside the loop.

Type value;
do
{
    value = GetCurrentValue(); 
    Process(value);
}while(condition(value));

I don't like this for at least two reasons. For one, I like declaring things locally. And second, this is a problem if value is not assignable or default-constructible, but only copy-constructible.

So, my question has two sides. First, I'd like to know if there was a particular reason/difficulty in extending the do while's scope to the final condition as well (just as the scope of variables declared in for loop includes the body of the for loop despite it physically being outside of the braces). And if you believe that the answer to my first question is "It's just the way it is. Don't ask why questions." then I'd like to know if there are idioms that can help write do-while loops similar to the ones in my example but without the downsides I mentioned.

Hope the questions are clear.

Answer 1

There is a good reason why variables declared inside the do-while loop body are out of scope in its condition expression: reduce the possibilities to deal with undefined behavior due to uninitialized variables.

Consider a slight variation of your example snippet:

do {
     if (not_ready_yet()) {
         sleep(1);
         continue;
     }
     Type value(GetCurrentValue());
     Process(value);
} while (condition(value)); // error

If C++ would allow a loop-scoped variable to be used in the loop condition, such a jump (via continue) to the condition expression would yield undefined behavior because it accesses an uninitialized variable (value in our example).

Having it the way it is, such errors can't be made.

---

Since C++ allows for many ways to use uninitialized variables, such as

for (int j; j<10; ++j)
    do_something();

or

int foo(int i) {
    if (i > 10)
        goto end;
    int x = 23;
end:
    return x;
}

or just

int foo(int i)
{
    int k;
    return k + i + 1;
}

the above reason might not be what drove the designers of the do-while loop, in the first place.

---

Having it the current way simplifies the compiler (and language), because a compound statement that is a do-while loop body has the exact same scoping rules as all other compound statements.

This was perhaps a strong argument for early C compilers that had to deal with limited resources. And since C++ was built on C, there is a strong incentive to not change such elementary design decisions.

---

Looking at theoretical alternatives, besides changing scope-rules just for do-while, something like this could be an option:

do (Type value(GetCurrentValue())) {
     Process(value);
} while (condition(value));

However, this might confuse people on whether or not value is re-initialized each iteration.

---

With the current language, re-writing it like this isn't too bad, though:

for (;;) {
     Type value(GetCurrentValue());
     Process(value);
     if (!condition(value))
         break;
}

Just one more line than in your original snippet. And less to type than:

do {
     Type value(GetCurrentValue());
     Process(value);
     if (!condition(value))
         break;
} while (true);

Answer 2

If you'd like to keep value locally scoped for the while loop, you can do this instead:

do
{
     Type value(GetCurrentValue());
     Process(value);
     if (! condition(value) )
         break;
} while(true);

This is just personal preference, but I find while loops structured like the following more readable (while instead of do-while):

while(true) {
    Type value(GetCurrentValue());
    Process(value);
    if (! condition(value) ) {
        break;
    }
}

The scoping rules in C/C++ works as follows: Local variables declared within a brace {...} block is local / visible only to that block. For example:

int a = 1;
int b = 2; 
{
    int c = 3;
}
std::cout << a;
std::cout << b;
std::cout << c;

will complain about c being undeclared.

As for rationale - it's just a matter of consistency and "that's just how the language is defined"