On 9/26/07, Joseph Gauterin <joseph.gauterin@googlemail.com> 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