Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This back and forth conversion tp/from utf8 during this transition
| phase is a real hassle. Taking this decision now will simplify and
| speed-up greatly the transition. We also need quickly the operator
| that Georg is working on (+=, streams, etc).
Quickly is not "Now!"
Yes, going utf<-> is perhaps a hassle. But I must admit that I do not
see it as such. I see it among others as a way to discover where
different encodings are required and where unicode must be used.
Ad. the streams and such. For linux this is "solved" by using wchar_t.
This is not an option with win and other 2-byte wchar_t systems, so we
have to find a solution for those.
| > | Please speak-up if you don't agree with that.
| > I am not sure that I agree with Andre (or you) that we have to use
| > docstring all over internally.
| > Neither am I sure it is wise to introduce a myriad of "new" string
| > types.
|
| When do you think you will know your opinion? When you do, please
| explain why it is not wise. I can very well imagine that these new
| types could be extended depending on their use. Example:
Introducing a myriad of new types just so that you have something to
call them or separate them, when they are not likely to be confused
anyway is not the way to go.
| class Format: public KeyString
| {
| public:
| Format(bool supported = false): supported_(supported) {}
| bool isSupported() { return supported_; }
|
| private:
| bool supported_;
| };
Then it is even worse. It is not a std::basic_string anymore. At least
I prefere containment to inheritance when possible.
| Too many things remains stalled because you are not making up your
| mind.
Allow me a polite: Bull!
There plenty of non-controversial unicode tasks to work on.
Even if we and up going docstring-all-in, there is plenty of unicode
tasks. (Even frontend tasks.)
--
Lgb
