Boost logo

Boost :

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
| >
| > | "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,
but it
| > 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
in C++0x.


Boost list run by bdawes at, gregod at, cpdaniel at, john at