|
Boost : |
From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-05-11 06:34:52
"Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:00c101c55591$877dbab0$6401a8c0_at_pdimov2...
> | Thorsten Ottosen wrote:
> | > "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> | > news:02b001c554cd$47504940$6401a8c0_at_pdimov2...
> |
> | [...]
> |
> | >> for( [type] [identifier] : [expr] )
> | >> [statement]
> | >>
> | >> Let e of type E be the value of [expr]. For each iterator i in the
> | >> range
> | >>
> | >> - [ e.begin(), e.end() ) when E is not an array type;
> | >> - [ e, e + N ) when E is T[N],
> | >>
> | >> executes the compound statement
> | >>
> | >> {
> | >> [type] [identifier] = *i;
> | >> [statement]
> | >> }
> | >>
> | >>
> | >>
> | >> doesn't require library support.
> | >
> | > but it wouldn't work with pair<iterator,iterator> without an adapter.
> |
> | Correct.
>
> and it also makes it harder to treat const char[N] differently.
That's covered by Peter's suggestion.
> | I think that the benefits of not having to include <iterator> and
> | confining this to a pure core extension not requiring library support
> | outweigh the costs.
Agreed. I like the idea of this being essentially a rewrite-rule. If it calls
free functions rather than member functions it starts to depend on what
headers have been included, which seems rather fragile.
> | pair<iterator, iterator> is not the proper way to express an iterator range
> | anyway; its use in the standard library only serves to highlight the lack of
> | iterator_range<iterator>, or even range<iterator>, if you prefer.
>
> still, a lot of code depends on it...it seems really silly that this new
> construct
> should be made harder to use for those libraries.
I've never seen any code use pair<iterator,iterator>. Maybe I haven't looked
hard enough.
Anyway, you could add make_range() to a standard header that would handle the
necessary adaptation.
> An <std> header is the way to go IMO.
>
> anyway, I'll try to get a discussion on this in Quebec.
>
> | >> One reasonable extension
> | >
> | > perhaps. C++ is typed language.
> | >
> | >> would be to allow [type] to be omitted, ...
> |
> | This form is even more typed than the other, because it doesn't let you
> | accidentally supply a wrong type.
>
> for( auto i : vec )
> ;
>
> will already work
I think that explicitly specifying the type (even if "auto") is a good
idea. It would seem inconsistent with normal for if you could not reuse an
existing variable, or if a new variable was introduced without a type
declaration.
Also, IIRC, in C# (or was it C++/CLI?) you can reuse an existing variable.
Anthony
-- Anthony Williams Software Developer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk