An advantage is that I do not need to care about iterator types.
At the expense of making many useful operations *impossible*, let me give you one use case - in fact the motivating reason for creating an iterator based regex lib: Imagine you have a text editor, it contains text in a contain-of-containers, representing a vector of lines (I'm talking logically not literally here, you don't actually have to have a vector of vectors, but it looks like that in the interface). You can easily create a composite iterator that enumerates all the characters in the whole text, but to do anything with that you need an iterator agnostic string algorithm library. Or... Imagine you have a text file that's too large to fit into program memory, you could create a custom iterator that loads on demand the part of the file it's pointing at, but looks to the outside world like a continuous sequence of several gigabytes of characters. And yes the regex lib has been used to search multi-gigabyte archives like this. In the early days of the lib (before Boost or BB for short <g>), I also used this technique to search large files under MS-DOS without breaking through the 64K segment limit.
I still don't see any good reason to it. String algorithms are primary based on *strings* and not *char type*. A string is first of all a container.
Exactly - they are based on strings, not string iterators. But if we agree that all strings (we are interested to cover with this library) are parameterized by character type we could use char type parameterization
As such thare are several options of its internal representation, none of them superior to other in all possible use cases.
The only reasonble abstraction we have so far is through iterators.
IMO iterator abstraction is unnachural for strings. Unless we are talking about unicode in 99.99% of cases string is just some_template
Sorry, but that's rubbish, at least as far as legacy string types are concerned, and as I said users are pretty much forced to use these in many situations. That's not to say that we can't have algorithm overloads that accept a string type rather than an iterator pair as argument (regex works this way), given a suitable string_traits<> or whatever the library could then adapt to almost any string type. In fact I have never found a string class that can't be converted to an iterator pair (and believe me I've seen a lot of string classes!) John.