From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2005-05-11 11:38:38
"Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> "Anthony Williams" <anthony_w.geo_at_[hidden]> wrote in message
> | "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,
So, you would *enforce* that char arrays were treated as null-terminated
strings? Ouch. No thanks. If I want a char array treated as a string, I'll
cast it to a std::string, or pass it through make_range.
That would create a special case like std::vector<bool>. I might use an array
of chars just as an array of small integers, and iterating through it should
therefore go all the way to the end, not one before. Besides, if I think it's
a null-terminated string, I don't want all-but-the-last-byte-in-the-array, I
want up-to-the-null-terminator, which may be in the middle of the array.
> | > | pair<iterator, iterator> is not the proper way to express an iterator
> | > | 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
Ah. I've never found a use for equal_range (member or not), or boost.graph.
> 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
> if you must rely on member function vs. being able to use free-standing
If the implementation uses free standing functions, you need to write begin()
and end() for your type. If the implementation uses members, you can write
make_range() for your type, *or* write the members.
> | 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.
Eventually. C++/CLI will likely ship before C++0x, and they're not going to
drop their "for each" construct now:
for each ( type-specifier-seq declarator in assignment-expression ) statement
even if they add the C++0x version as well.
-- 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