|
Boost : |
Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-21 12:56:36
On Sat, Jan 22, 2011 at 1:37 AM, Chad Nelson
<chad.thecomfychair_at_[hidden]> wrote:
> On Fri, 21 Jan 2011 20:07:51 +0800
> Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
>
>> [...] Mostly I'm interested in seeing a string class that is:
>>
>> 1. Immutable. No if's or but's about it. I don't want a string to be
>> modifiable. Period. You can create it, and once it's created, that's
>> it. [...]
>
> I'm confused by this. You want the basic type to always act as if it's
> const, with no way to modify the string at ALL after it's been created?
>
Yep.
No changing arbitrary content in the string. Concatenation is a
process of creating new strings.
>> I think strings are different from the encoding they're interpreted
>> as. Let's fix the problem of a string data structure first then tack
>> on encoding/decoding as something that depends on the string
>> abstraction first.
>
> That gets back to the problem that I was originally trying to solve
> with the UTF types: that a string needs a way to carry around its
> encoding. A UTF-8 type could be built on such a thing very easily.
Hmm... I OTOH don't think the encoding should be part of the string.
The encoding is really external to the string, more like a function
that is applied to the string.
If you can wrap the string in a UTF-8, UTF-16, UTF-32 encoder/decoder
then that should be the way to go. However building it into the string
is not something that will scale in case there are other encodings
that would be supported -- think about not just Unicode, but things
like Base64, Zip, <insert encoding here>.
Ultimately the underlying string should be efficient and could be
operated upon in a predictable manner. It should be lightweight so
that it can be referred to in many different situations and there
should be an infinite number of possibilities for what you can use a
string for.
-- 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