 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
kwikius
Guest
|
 Posted: Sat Mar 17, 2007 4:09 pm Post subject: Benefit of new style for loop N1796 |
 |
|
I'm wondering how much value the for proposal (N1796) adds compared to
the implementation complexity.
Consider the motivating example.
vector<int> vec = ...;
for( int i : vec )
std::cout << i;
The current language this can be expressed (most obviously and
ignoring performance) by:
for (std::vector<int>::iterator iter = vec.begin(); iter!= vec.end();+
+iter)
std::cout << *iter;
The main inconvenience here is typing out the member iterator, Using
auto most of this inconvenience goes:
for ( auto iter= vec.begin(); iter!= vec.end();++iter)
std::cout << *iter;
A major disadvantage of the new style for loop is that you cannot
query the iterator, so limiting its use to only uniform actions on
each element. The limits of use of this can be seen from the given
example.In a real example one would presumably apply a separator
between the output values, leaving the untidy issue of adding an
unnecessary separator at the end.( which could be solved only by being
able to query the iterator) The proposal also couples language and
library features in a way that is not done anywhere else in the
language and therefore feels somewhat out of the spirit of C++ to me
anyway.
Each additional language feature has a cost in that it must be
implemented. In this case is the benfit worth it, especially
considering the large number of other features that must be
implemented?
regards
Andy Little
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
 |
Douglas Gregor
Guest
|
| Posted: Sat Mar 17, 2007 6:43 pm Post subject: Re: Benefit of new style for loop N1796 |
|
|
On Mar 17, 12:09 pm, "kwikius" <a...@servocomm.freeserve.co.uk> wrote:
| Quote: | I'm wondering how much value the for proposal (N1796) adds compared to
the implementation complexity.
Consider the motivating example.
vector<int> vec = ...;
for( int i : vec )
std::cout << i;
[snip examples]
A major disadvantage of the new style for loop is that you cannot
query the iterator, so limiting its use to only uniform actions on
each element. The limits of use of this can be seen from the given
example.In a real example one would presumably apply a separator
between the output values, leaving the untidy issue of adding an
unnecessary separator at the end.( which could be solved only by being
able to query the iterator)
|
Why not just use a "bool" flag?
| Quote: | The proposal also couples language and
library features in a way that is not done anywhere else in the
language and therefore feels somewhat out of the spirit of C++ to me
anyway.
|
type_info does this already, as do type traits.
| Quote: | Each additional language feature has a cost in that it must be
implemented. In this case is the benfit worth it, especially
considering the large number of other features that must be
implemented?
|
I'd suggest looking at one of the newer, concept-based formulations of
the range-based "for" loop. They're a lot cleaner, more robust, and
easier to understand. Check out one of:
N2049: My two-page discussion of using concepts for the range-based
for loop
N2196: Thorsten's revised wording for the range-based for loop
Is the feature worth the cost? I think so, because the lack of a
simple way to iterate over all of the elements in a container is one
small thing that makes it just slightly too hard to write code, and
also has the effect of making C++ look a bit dated. The feature is
quite simple to implement; it's probably about 100 lines of code in
ConceptGCC right now, and took only a few hours to do, so I wouldn't
worry about the implementation cost.
Cheers,
Doug
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Andrei Polushin
Guest
|
| Posted: Mon Mar 19, 2007 5:26 am Post subject: Re: Benefit of new style for loop N1796 |
|
|
kwikius wrote:
| Quote: | I'm wondering how much value the for proposal (N1796) adds compared to
the implementation complexity.
Consider the motivating example.
vector<int> vec = ...;
for( int i : vec )
std::cout << i;
[...] The proposal also couples language and
library features in a way that is not done anywhere else in the
language and therefore feels somewhat out of the spirit of C++ to me
anyway.
|
That's an important objection. The range-based for loop could have
a possible generalization when we will have some kind of lambda
proposal accepted.
The range-based loop is a combination of for_each() standard
algorithm, and a local anonymous function. So we may just vary
a function invocation syntax in a way similar to N1796:
vector<int> vec;
/-------------------------- algorithm function name
|
| /----------------- local function parameter(s)
| __|__
| / \ /---------- algorithm parameter(s)
| | | |
for_each (int& i : vec) <------ algorithm invocation
{ --\
cout << i << endl; |---- local function body inlined
} --/
Where for_each() is declared in the way that allows lambda for the
last parameter, e.g.:
template <class C, class F, class V>
void for_each(C cont, F func(V val) = <<lambda )
{
for (auto it = cont.begin(); it != cont.end(); ++it) {
func(val);
}
}
FWIW, the examples of "for-loop" syntax applied to other algorithms:
vector<int> vec;
// sort(vec.begin(), vec.end(), <<lambda )
sort(int& a, int& b : vec) {
yield a < b; // bool lambda(int& a, int& b)
}
// long n = accumulate(vec.begin(), vec.end(), 0, <<lambda )
long n = accumulate(int& a, int& b : vec, 0) {
yield a * b; // int lambda(int& a, int& b)
}
(The above is NOT yet another lambda proposal, but just to confirm
that the new syntax of "for" loop could be a pure language feature,
less coupled with the standard library).
--
Andrei Polushin
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
kwikius
Guest
|
| Posted: Mon Mar 19, 2007 5:48 pm Post subject: Re: Benefit of new style for loop N1796 |
|
|
On 17 Mar, 18:43, "Douglas Gregor" <doug.gre...@gmail.com> wrote:
| Quote: | On Mar 17, 12:09 pm, "kwikius" <a...@servocomm.freeserve.co.uk> wrote:
... |
| Quote: | [snip examples]
A major disadvantage of the new style for loop is that you cannot
query the iterator, so limiting its use to only uniform actions on
each element. The limits of use of this can be seen from the given
example.In a real example one would presumably apply a separator
between the output values, leaving the untidy issue of adding an
unnecessary separator at the end.( which could be solved only by being
able to query the iterator)
Why not just use a "bool" flag?
|
I don't understand what you mean? There are many aspects to querying
the iterator, dependent on the type of iterator:
std::vector<T> vec;
for ( BOOST_AUTO( iter, vec.begin()); iter!= vec.end() {
if (iter == vec.begin())
std::cout << '(';
std::cout << *iter++;
if ((iter - vec.begin()) % 3){
std::cout << ' ';
}
else{
std::cout << ")\n";
if (iter != vec.end())
std::cout << '(';
}
}
| Quote: | The proposal also couples language and
library features in a way that is not done anywhere else in the
language and therefore feels somewhat out of the spirit of C++ to me
anyway.
type_info does this already, as do type traits.
|
These facilities are structural. They work uniformly on raw types.
The for loop works only for one high level concept. IOW these examples
are not equivalent.
This proposal is more akin the D approach of enshrining complex in the
language.
| Quote: | Each additional language feature has a cost in that it must be
implemented. In this case is the benfit worth it, especially
considering the large number of other features that must be
implemented?
I'd suggest looking at one of the newer, concept-based formulations of
the range-based "for" loop. They're a lot cleaner, more robust, and
easier to understand. Check out one of:
N2049: My two-page discussion of using concepts for the range-based
for loop
N2196: Thorsten's revised wording for the range-based for loop
Is the feature worth the cost? I think so, because the lack of a
simple way to iterate over all of the elements in a container is one
small thing that makes it just slightly too hard to write code, and
also has the effect of making C++ look a bit dated. The feature is
quite simple to implement; it's probably about 100 lines of code in
ConceptGCC right now, and took only a few hours to do, so I wouldn't
worry about the implementation cost.
|
The complexity of current C++ compilers is a known problem. Its
difficult to predict which straw it is that will break the camels
back.
In practise implementing a feature involves a huge amount more work
than just code. There is testing over a wide range of containers
documentation and specification.
regards
Andy Little
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Richard Smith
Guest
|
| Posted: Mon Mar 19, 2007 5:50 pm Post subject: Re: Benefit of new style for loop N1796 |
|
|
On Mar 17, 6:43 pm, "Douglas Gregor" <doug.gre...@gmail.com> wrote:
| Quote: | On Mar 17, 12:09 pm, "kwikius" <a...@servocomm.freeserve.co.uk> wrote:
Each additional language feature has a cost in that it must be
implemented. In this case is the benfit worth it, especially
considering the large number of other features that must be
implemented?
I'd suggest looking at one of the newer, concept-based formulations of
the range-based "for" loop. They're a lot cleaner, more robust, and
easier to understand. Check out one of:
N2049: My two-page discussion of using concepts for the range-based
for loop
N2196: Thorsten's revised wording for the range-based for loop
|
Is there a reason why the
for ( int x : v ) {}
syntax was chosen instead of the existing C++/CLI syntax?
for each ( int x in v ) {}
It seems that as the latter syntax already exists and is in use, using
it for the concept-based for-loop would make sense too help write
generic code and eliminate an unnecessary difference between ISO C++
and C++/CLI. It shouldn't be incompatible with C++/CLI usage as a
concept_map can be written for IEnumerable subtypes.
--
Richard Smith
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Marcus Kwok
Guest
|
| Posted: Mon Mar 19, 2007 8:35 pm Post subject: Re: Benefit of new style for loop N1796 |
|
|
Richard Smith <richard@ex-parrot.com> wrote:
| Quote: | Is there a reason why the
for ( int x : v ) {}
syntax was chosen instead of the existing C++/CLI syntax?
for each ( int x in v ) {}
It seems that as the latter syntax already exists and is in use, using
it for the concept-based for-loop would make sense too help write
generic code and eliminate an unnecessary difference between ISO C++
and C++/CLI. It shouldn't be incompatible with C++/CLI usage as a
concept_map can be written for IEnumerable subtypes.
|
I think the issue with the C++/CLI syntax is that "for each" and "in"
are context-sensitive keywords[0], and as far as I know, standard C++
has context-free keywords.
[0] http://msdn2.microsoft.com/en-us/library/8d7y7wz6(VS.80).aspx
--
Marcus Kwok
Replace 'invalid' with 'net' to reply
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Richard Smith
Guest
|
| Posted: Tue Mar 20, 2007 5:03 am Post subject: Re: Benefit of new style for loop N1796 |
|
|
On Mar 19, 8:35 pm, ricec...@gehennom.invalid (Marcus Kwok) wrote:
| Quote: | Richard Smith <rich...@ex-parrot.com> wrote:
Is there a reason why the
for ( int x : v ) {}
syntax was chosen instead of the existing C++/CLI syntax?
for each ( int x in v ) {}
I think the issue with the C++/CLI syntax is that "for each" and "in"
are context-sensitive keywords[0], and as far as I know, standard C++
has context-free keywords.
|
Nearly. "in" is a context-sensitive keyword, but "for each" is a
whitespace keyword. (I.e. "each" is not a keyword, but "for each" is
a single keyword.)
But that doesn't answer the question: why was the former chosen over
the latter? What's wrong with ISO C++ using context-sensitive and/or
whitespace keywords? It clearly can be implemented as it is in use in
MSVC's C++/CLI implementation. Using the same syntax as C++/CLI seems
to make sense if there aren't any good reasons not to.
--
Richard Smith
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
David Abrahams
Guest
|
| Posted: Tue Mar 20, 2007 11:16 pm Post subject: Re: Benefit of new style for loop N1796 |
|
|
on Tue Mar 20 2007, thorsten.ottosen-AT-dezide.com (Thorsten Ottosen) wrote:
| Quote: | kwikius skrev:
On 19 Mar, 15:20, thorsten.otto...@dezide.com (Thorsten Ottosen)
wrote:
just a you can make an indirection iterator, I guess you can make an
"outdirection" irerator:
for( auto iter : make_outdirection_range( vec ) )
iter->foo();
OK I don't understand how the above works but if it provides access
the iterator , great...
you simply need an iterator adaptor where operator*() returns the
iterator itself instead of giving an indirection.
|
Try boost::counting_iterator<...>.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Thorsten Ottosen
Guest
|
| Posted: Wed Mar 21, 2007 1:31 am Post subject: Re: Benefit of new style for loop N1796 |
|
|
kwikius skrev:
| Quote: | On 19 Mar, 15:20, thorsten.otto...@dezide.com (Thorsten Ottosen)
wrote:
just a you can make an indirection iterator, I guess you can make an
"outdirection" irerator:
for( auto iter : make_outdirection_range( vec ) )
iter->foo();
OK I don't understand how the above works but if it provides access
the iterator , great...
|
you simply need an iterator adaptor where operator*() returns the
iterator itself instead of giving an indirection.
make_outdirection_range() then returns the orignal begin/end pair
of vec wrapped in that iterator adaptor.
| Quote: | First, apologies as I seem to keep laying into your proposals.
|
no apology needed.
-Thorsten
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
kwikius
Guest
|
| Posted: Wed Apr 25, 2007 10:40 am Post subject: Re: Benefit of new style for loop N1796 |
|
|
On 20 Mar, 18:49, "Douglas Gregor" <doug.gre...@gmail.com> wrote:
| Quote: | On Mar 19, 1:48 pm, "kwikius" <a...@servocomm.freeserve.co.uk> wrote:
The complexity of current C++ compilers is a known problem. Its
difficult to predict which straw it is that will break the camels
back.
Jedi mind trick>This is not the straw you are looking for.</Jedi mind
trick
|
I don't understand the above comment and annotations etc. Perhaps you
could spell out less cryptically what you mean here?
regards
Andy Little
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Douglas Gregor
Guest
|
| Posted: Thu Apr 26, 2007 5:06 pm Post subject: Re: Benefit of new style for loop N1796 |
|
|
On Apr 25, 6:40 am, kwikius <a...@servocomm.freeserve.co.uk> wrote:
| Quote: | On 20 Mar, 18:49, "Douglas Gregor" <doug.gre...@gmail.com> wrote:
On Mar 19, 1:48 pm, "kwikius" <a...@servocomm.freeserve.co.uk> wrote:
The complexity of current C++ compilers is a known problem. Its
difficult to predict which straw it is that will break the camels
back.
Jedi mind trick>This is not the straw you are looking for.</Jedi mind
trick
I don't understand the above comment and annotations etc. Perhaps you
could spell out less cryptically what you mean here?
|
*Sigh* It was a joke. You claimed that the addition of little features
is going to cause a break-down somewhere in C++ compilers due to their
implementation complexity. I completely disagree... small features
won't break a C++ compiler that can already handle most of C++98. If
you're going to be concerned about implementation complexity in C++0x,
there are much larger proposals that have a more fundamental effect on
the way C++ compilers process templates and optimize code.
The Jedi mind trick refers to Star Wars episode 4; look for "These
aren't the droids you're looking for" at http://www.imdb.com/title/tt0076759/quotes.
It was my subtle way of telling you that the range-based for loop
isn't going to be the straw that breaks any C++ compiler-camel's back.
- Doug
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
