"Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message news:fywten01.fsf@yahoo.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "Anthony Williams" <anthony_w.geo@yahoo.com> wrote in message | > news:k6m6f12b.fsf@yahoo.com... | > | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | > | | > | > "Peter Dimov" <pdimov@mmltd.net> 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]. | | 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. well' that the behavior currently. The string algorithms rely on this behavior. | 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. char[] might be wrongly specified today, const char[] is not. | > 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. | | 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. yep, but the latter approach is harder and takes just about twice as much code in C++0x. -Thorsten