Re: Benefit of new style for loop N1796
On 17 Mar, 18:43, "Douglas Gregor" <doug.gre...@gmail.com> wrote:
On Mar 17, 12:09 pm, "kwikius" <a...@servocomm.freeserve.co.uk> wrote:
<...>
[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 << '(';
}
}
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.
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 ]