On Fri, Jan 28, 2011 at 2:16 AM, David Bergman <David.Bergman@bergmangupta.com> wrote:
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 thinking about.
Is that the "boost::string" class you are proposing? Although immutable...
Nope.
So, we should rid the notion of silly text-handling and focus on the sequentiality of a (CS...) string?
NO. 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