Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-23 21:16:45

On Sat, Jan 22, 2011 at 5:01 AM, Nevin Liber <nevin_at_[hidden]> wrote:
> On 21 January 2011 06:07, Dean Michael Berris <mikhailberis_at_[hidden]>wrote:
>
>> 4. Looks like a real STL container except the iterator type is smarter
>> than your average iterator.
>>
>
> What does "smarter" mean?

The way I was thinking about it, "smarter" would mean something along
the lines of "knows more than your average <thing>" where <thing> is a
bare iterator.

In the context of strings, I was thinking it should be able to know
what string it came from, what encoding is the string supposed to be
interpreted in, or whether there are special computations that an
iterator for string might need. One example that comes to mind is
having a tokenizing iterator which returns a string when dereferenced
and knows what the delimiters of the string are -- to do that
correctly your iterator would need to know which string it came from
and where in the string its internal "counter" is already "parked" at
from the last dereference.

This would require that iterators be built externally from the string,
something like:

  auto it = encoded<utf8_encoding>(original_string), end =
encoded<utf8_encoding>();

Here `it` could interpret the original string as UTF-8 and you can
possibly assume that dereferencing this iterator can return an
appropriate (possibly variant) type that is convertible to the
appropriate holder (char, wchar_t, uint32_t (for utf32)). From here
you can build ranges appropriately and deal with ranges and just know
that the encoding is explicitly defined in the iterator.

HTH

-- 
Dean Michael Berris
about.me/deanberris