Re: [Boost-users] Report from Mont Tremblant C++ Committee meeting

From: John Maddock (john_at_[hidden])
Date: 2005-10-12 04:55:43

> 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<char_type>

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.