Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-28 03:25:59
On Fri, Jan 28, 2011 at 2:16 AM, David Bergman
> On Jan 27, 2011, at 10:22 AM, Dean Michael Berris wrote:
>> Definitely. Which is why I still think about a string and think "oh,
>> sequence of something" rather than see string and think "oh, text!".
> Ok, so we are back to std::vector again...
Well, std::vector implies that it's contiguous. That's not what I'm
> Is that the "boost::string" class you are proposing? Although immutable...
> So, we should rid the notion of silly text-handling and focus on the sequentiality of a (CS...) string?
The point is that there are two levels being discussed and that I have
an idea on how to fix both by solving one level one way.
The string, an underlying data structure that has its own semantics
and algorithms that apply to it (substring, concatenation, etc.) would
be a foundation for a view (encoded, compressed, etc.) which has its
own semantics and interface similar to a string -- and offer more than
what a bare string would offer. In my mind I see interpreting data in
a string through some lens is actually a different concern from how
the string actually behaves (and what a string is).
So what I'm really saying is -- and has been from the beginning --
let's fix the borkedness of std::string by coming up with a string
that is immutable, crazy efficient to deal with, has real value
semantics, and a whole family of algorithms that deal with this
newfangled string. Then on top of that let's implement views of these
strings in the encoding we would like and implement algorithms that
deal with coercing a given string to be viewed in a given encoding.
The point is I'm talking in concepts and interfaces of two different
things. Now if "a string that has its encoded intrinsic to its type"
is really a 'view<encoding>' in my parlance then that's what I mean.
Does that make sense?
-- Dean Michael Berris about.me/deanberris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk