From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-05-11 12:06:31
"Anthony Williams" <anthony_w.geo_at_[hidden]> wrote in message
| "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
| > "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].
| 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
| That would create a special case like std::vector<bool>. I might use an
| 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
| 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,
| > does seem non-optimal to me.
| > consider, for example, the amount of work you need to do to support your
| > 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
| 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk