Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-28 03:34:57

On Fri, Jan 28, 2011 at 5:57 AM, Patrick Horgan <phorgan1_at_[hidden]> 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