In the below example, i has function scope. But it seems that I cannot use i in the second for loop. Why does for (i : v1) not work, but for (int i : v1) works?
#include<iostream>
#include<string>
#include<vector>
int main()
{
std::vector<int> v1;
int i;
while(std::cin>>i)
{
v1.push_back(i);
}
for(i : v1) //for (int i:v1) works
std::cout<<i<<"\t";
cout<<std::endl;
return 0;
}
It's a syntactical issue that a range-based for loop requires a declaration of a named variable, i.e. it requires a type specifier (cf, for example, cppreference.com):
for ( range_declaration : range_expression ) loop_statement
range_declaration - a declaration of a named variable, whose type is the type of the element of the sequence represented by range_expression, or a reference to that type. Often uses the auto specifier for automatic type deduction
Actually I don't know why your question got downvoted; I find your assumption quite OK; just the C++ syntax has decided to define it in another way.
The range-based for is specifically intended to replace loops akin to the following (this is a somewhat simplistic case; range-based for, especially the C++17 version, is more general than the example):
for (auto it = range.begin(), end = range.end(); it != end; ++it) {
use(*it);
}
In the majority of cases won't use the values at the different locations but will rather use the element at the location itself:
As a result the designers of range-based for decided that references absolutely have to be supported. At the same time, it was intended to use a reasonably simplistic rewrite-rule for a range-based for. The rule which is codified in the standard is this:
for (<range-decl>: <range>) { <body> }
is equivalent to
{
auto&& range = <range>; // keep the range alive!
auto it = begin(range); // actually, reality is bit more complicated
auto end = end(range); // actually, reality is a bit more complicated
for (; it != end; ++it) {
<range-decl> = *it; // this is the rewrite causing your issue
<body>
}
}
In particular, the implication is that <range-decl> is a declaration rather than just naming a variable. The reason for this requirement is that typically the entity used in front of the : is a reference. However, references cannot be rebound. However, in each iteration of a loop a new reference can be used.
In principle the rewrite rule could work with using assignments if the <range-decl> isn’t a declaration but rather an lvalue. That would yield its own share of odd behaviors:
for (T const& x: range) and T const& x = 0; for (x: range): the former works while the latter is an error.T& x = get_reference(); for (x: range) {...}) the loop would automatically assign all the values in a range to an object located somewhere. Normally the objects are either located on the stack or in the source range (when the variable is declared as a reference).It was consider more reasonable to only allow initialisations than supporting initialisation or assignments depending on how the variable is declared. Looking at the revision history of the proposals (N2930 and predecessors) doesn’t yield a discussion but I vaguely recall that ths point was discussed.
<range-decl> couldn't be optionally a declaration or an lvalue. If we go by simple text replacement rule, this wouldn't be a problem.
When you are using range-based loops you need a declaration after opening parentheses, not only a variable. The correct syntax is:
for ( declaration : range ) statement;
You can see this link for more information.
In your example: when you declare i before your while loop then you can use it in all of the main function and the scope of it is the main function. You can use it in that for body. When you are using the i variable in your for range then you aren't declaring it, because you already declared it above, so it will give you an error and it's not correct with C++ syntax.
But when you type int before the i in your for parenthesis then you are declaring another variable with the name of i, but only for your for loop and then it is OK with C++ syntax.
The rationale is most likely because this would invoke copy-assignments on the variable, which would become a potential source of great inefficiency and in practice almost never be the intention... if the type supports copy-assignment at all.
So they probably figured it's best to prohibit this.
forrequires a declaration rather than merely naming a variable. ... and I'd be surprised if typical textbooks cover the rational for this oddity.int i; for(i = 0; i < 10; ++i)used. Not such a big leap to try that on a range-based for as well.forand it is actually illogical that it is not supported! There is a reason but I think this reason may even be somewhat feeble...