|
Boost : |
Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-27 05:57:54
On Thu, Jan 27, 2011 at 4:49 PM, Patrick Horgan <phorgan1_at_[hidden]> wrote:
> On 01/26/2011 11:34 PM, Dean Michael Berris wrote:
>>
>> So you're saying, utf8_string is not view<utf8_encoding> Â as far as
>> I've already described it?
>
> Exactly. Â Others have expressed repeatedly that they want a string with
> intrinsic encoding.
So isn't the encoding intrinsic in the view here? I don't get the difference.
If you can use a view<...> in place of a string, what is the difference?
>> Really, if you read the recent discussions, you will see that we're
>> really talking about the same thing: a data structure that knew the
>> encoding somehow. That somehow is, and has been determined (and agreed
>> upon already) already suitably modeled by a view<...> Â that takes a
>> string for a suitable definition of string. Note that the string *has
>> no encoding that is intrinsic to it*.
>
> Yes. Â I understand clearly that you have been talking about that. Â Others
> talked about a string with intrinsic encoding.
Which I've already addressed with a view<...> template. What else do
others want?
>> So Mr. Berris is saying right now, if you didn't see the point: your
>> "utf8_string" is really just a typedef to view<utf8_encoding>. The
>> only *reasonably efficient* way of achieving this view design is if
>> you had immutable strings. The thread has already hashed out *why*
>> mutable strings is a bad thing (performance and design-wise) for
>> encoding-aware algorithms. I don't see why we need to go back to that
>> *again*.
>
> Me either. Â Of course the other discussion about strings with intrinsic
> encoding should be in another thread.
The title of the thread is [boost][string] proposal -- I don't see why
it should be in another thread. Am I missing something?
>>
>> At any rate feel free to convince me otherwise that immutable strings
>> wouldn't be a good thing for
>> encoding/transcoding/string-or-text-centric algorithms. ;)
>
> Why on earth would I do that? Â They would be wonderful for many applications
> and as you said and I agreed to days ago, why would you want to pay an extra
> price for a mutable string when you didn't need one. Â Of course when you did
> need one you'd just use it.
>
> I'd just like to see your thread as you began it, a discussion about the
> benefits of an immutable string. Â I particularly didn't like that it got
> hijacked to focus on how appropriate it would be for a string that
> represented a particular encoding. Â Of course that's something to think
> about but there's a lot more to the benefits of an immutable string than
> that, and you started off doing a good job of discussing it before you got
> distracted. Â I just want to see the discussions split again so in this
> thread discussions of all aspects of immutability vs mutability could be
> discussed. Â It seems now that you are only interested in discussing
> encodings and views. Â I wanted the discussion of immutability.
>
Right.
So more to the point, the real thing I want to focus on is the
immutable string. :)
Although with the question about encoding, the answer is the view. :D
HTH
-- 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