Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-21 07:07:51

On Fri, Jan 21, 2011 at 7:25 PM, Matus Chochlik <chochlik_at_[hidden]> wrote:
> Dear list,
>
> following the whole string encoding discussion I would like
> to make some suggestions.
>
[snip]
>
> Let us create a class called boost::string that will have
> all the properties that a string handling class in 2011+ A.D.
> should have, basically what std::string should have been.
>

+1

[snip]
>
> Also I've uploaded into the vault file string_proposal.zip
> containing my (naive and un-expert-ly) idea what the
> interface for boost::string and the related-classes could
> look like (it still needs some work and it is completelly
> un-optimized, un-beautified, etc.).
>
> /me ducks and covers :)
>

Maybe you have a publicly available Git repository -- maybe on Github
-- we'd have a better discussion going?

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.

2. Has real value semantics. This means, once you've copied it, that's
really copied. No funky copy-on-write reference-counting mumbo-jumbo.

3. Has all the algorithms that apply to it defined externally.

4. Looks like a real STL container except the iterator type is smarter
than your average iterator.

Encoding is a matter of external interpretation and I think should not
be part of a string's interface. You can have wrappers that interpret
a string as a UTF-* string.

> The idea is that, let std::string/wstring be platform-specifically-
> -encoded as it is now, but also let the boost::string handle
> the conversions as transparently as possible so if in
> case the standard adopts it, std::string would become
> a synonym for boost::string.
>

Hmmm... I rather much have a string class that works first and can
later be decorated to be assumed/verified to be in a given encoding.

[snip]
>
> If this or something completely different and much better
> that comes out of it, will be agreed upon, we could set up
> a dedicated git repository for Boost.String and maybe try if
> the new suggested collaborative development in
> per-boost-component repositories really works. :)
> If some of the people that are skilled with unicode
> would join or lead the effort it would be awesome.
>

+1 -- collaborative development FTW. :)

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.

HTH

-- 
Dean Michael Berris
about.me/deanberris