From: Pavol Droba (droba_at_[hidden])
Date: 2004-05-08 13:17:06
On Sat, May 08, 2004 at 10:07:30PM +1000, Thorsten Ottosen wrote:
> | > Pavol uses it havily in his string library. The "dangerous" thing would be not to put
> | > computation of the end-iterator out-side the loop, eg.
> | >
> | > for( iterator_type_of<T>::type i = begin( c ); i != end( c ); ... )
> | > ^^^^^^^^^^ ^
> | > is not good. But one wouldn't do that anyway. And if one did it, what are the chances of
> | > the argument being a char*?
> | Too many chances are being taken here, IMO.
> the more chances that are taken, the less the likelihood of it all happening.
> | It doesn't feel right.
> | STL's end is guaranteed O(1) and I'm really concerned about anything
> | that violates that expectation.
> ok. I have forgotte why Pavol want to support char* at all. I mean, programming with manual
> insertion of null is really error-prone. If char* is considered a range, one might even say
> std::string s;
> my_algo( s.buffer() ); // oops, no terminating null!
There is a lot of legacy code out there with no counterpart in c++. I don't think, that we can afford
not to support it. Just have a look at the Boost Regex interface. char* is still there, and
there are reasons for it.
An implication of supporting char* is the requirement, that char must be threated the same way.
If you consider the way how std::string's end() works you have the current specification of the
collection traits for string.
An example of usecase for all string variants:
using namespace std;
using namespace boost;
int main(int argc, char* argv)
// check if the first argument contains "hello"
// char* is used for input char for search specifier
iterator_range<char*> r=find_first(argv, "hello");
if( !r.empty() )
// convert the find result (a pair of char*) to std::string
string str(r.begin(), r.end());
cout << str << endl;
An example may not be very usable, but it shows a common pattern, when char*, char, and std::string
are used in one place.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk