[boost] Re: FOREACH / C++ "for" proposal

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-05-11 08:15:30

"Anthony Williams" <anthony_w.geo_at_[hidden]> wrote in message 
news:k6m6f12b.fsf_at_yahoo.com...
| "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
|
| > "Peter Dimov" <pdimov_at_[hidden]> wrote in message

| > and it also makes it harder to treat const char[N] differently.
|
| That's covered by Peter's suggestion.

it would need a special sentence saying if T is char, the range is [array, 
array+N-1].

| > | 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.

in what way is it 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.

look at std::map or boost.graph

| Anyway, you could add make_range() to a standard header that would handle 
the
| necessary adaptation.

true.

the member function idea is not something I have't considered in depth, but it 
does seem non-optimal to me.

consider, for example, the amount of work you need to do to support your own 
types
if you must rely on member function vs. being able to use free-standing 
functions.

|
| Also, IIRC, in C# (or was it C++/CLI?) you can reuse an existing variable.
|

I think the intend is that C++/CLI will adopt the C++ "for-each" eventually.

-Thorsten