Re: [boost] Strings tagged with their character set

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2007-09-26 17:38:19

On 9/26/07, Joseph Gauterin <joseph.gauterin_at_[hidden]> wrote:
>
> I'd add making the string classes immutable to the list.

You mean having two classes then, isnt it?
If not, how should I do to replace sub-strings? It is a very common use.

> That way dereferencing an iterator (by which I mean calling unary op*) of any
> type could then return a unicode code point by value.Mutable
> sequences that pretend to hold a different type than they actually do
> don't work well with C++ idoms (e.g. vector<bool>).

The real problem with vector<bool> is that it isn't a Container. But
std::string never was a container, so it is not a real problem.
Besides, we could have different "views" of a string. Mutable and
non-mutable ones, each with a different iterator class.

> Strings could be built using a stringstream like approach

I don't understand what you mean.

> or by using concatenation
> (with possible expression template optimizations).
>
> Making the iterator a byte iterator, not a code point iterator, pushes
> the responsibility for knowing how to handle the variable widthness of
> the different encodings back onto the user.

So what is your opinion about it? I find it very useless a byte
iterator, except for copying.

> There are certainly a lot of possibilities, and we should try to get
> some sort of consensus before we go further with this.

Agreed.

[snip]

> > Conversions.  My approach at present is to use iconv via a functor
> > that I wrote a while ago.  I believe iconv is widely available;
> > however, some implementations may support only a small set of character
> > sets.  Alternatives would be interesting.
>
> IIRC, iconv is licensed under the GPL, which would prevent it from
> being integrated into boost. We should make whatever interface we come
> up with easily extendable, so that people could write add support for
> whatever encoding they require, possibly using iconv if using GPL
> software isn't a problem with them.

I don't find it a problem, iconv wouldn't ship with Boost. So only who
could use iconv would build the library. Just like regex does with ICU
and iostreams does with zlib.

> > - Interaction with locales, internationalisation, and system APIs.
>
> We'll definitely need a way to convert to a raw pointer representation
> (like std::string.c_str()) for interaction with some APIs.

Surely.

>
> Lots to think about.

So let's start ;)

Regards,
-- 
Felipe Magno de Almeida