On Fri, Jan 28, 2011 at 5:57 AM, Patrick Horgan <phorgan1@gmail.com> wrote:
Right, what I meant to say is that it hardly has any bearing when we're talking about engineering solutions. So your circumstances and mine may very well be different, but that doesn't change that we're trying to solve the same problem. :)
No. You're not trying to solve the same problem at all! (And neither of you are trying to deal with std::string.)
You, Dean, are trying to solve an efficiency problem caused by mutable strings, and note that an external view can interpret as any encoding desired. You correctly point out that this is more general and flexible, that it has a power that can be applied to many things while giving you all the efficiency advantages of immutable data types. (Although why a general buffer for immutable data would be called string which is normally associated with text _is_ a bit confusing. I suspect you've gone down a road you never intended trying to make this point.)
Well, you're correct for the most part. Except I really did mean to call them strings. ;)
You, Matus, are trying to solve a problem caused by a plethora of possible encodings and the extra work that has to be done every time you have to deal with them, by specifying that a string will have an encoding type associated with it, (and in particular utf-8 as the natural default), and that the specialized string itself will enforce the encoding as well as provide ways to convert other encodings to it. (And I think the natural way to do this is with code conversion facets.) You correctly point out that this specificity allows a power in solving this one particular problem that a more general solution wouldn't be able to match. A general string with a view into it would allow you to get invalidly encoded data into it (N.B for an immutable string _into it_ would have a different meaning) and you would only know about this after the fact.
But validation is an algorithm, right? Why can't validation be enforced in a special view implementation? Perhaps an (ugly) throwing constructor of a view to enforce the encoding would be something that could be put in if that's the only proble... right?
These are both great things. Kudos to you both. You're both right. You guys keep arguing apples and orangutans and it makes it hard for others to talk about either one of your ideas because you're so busy going back and forth telling each other that the other doesn't get what they're trying to say.
I wish you'd split into threads like [immutable string] and [unicode string].
Although I think you're right that it's probably better to deal with the underlying strings issue in a different thread, it does invariably affect the way the algorithms for encoding/transcoding would be implemented. And then as C++ programmers that we are we will get into the efficiency advantages/disadvantages of one aspect or another at a later given time -- or we might not, remains to be seen I know. :D So sure, but I think I've pointed out enough about what I think -- if others still have questions about the immutable strings and views idea, you know which thread to reply to. :) -- Dean Michael Berris about.me/deanberris