On środa 18 grudzień 2002 10:07 am, Lars Gullik Bjønnes wrote: > Kuba Ober <[EMAIL PROTECTED]> writes: > >> Unicodification is a big and dangerous job, and we will /still/ need > >> from/toqstr unless we use QString in lyx itself, which we probably do > >> not want to do. > | > | If the issue is to use std::string as the basic unicode-enabled string > | type, and easily use such strings in Qt environment, then I presume a > | very effective zero-copy translation function could be hacked if > | std::string is reference counted. It will be somewhat dependent on > | version of qt and std implementation, but I presume that ifdef's in > | performance-critical code are sorta allowed ;-). > | > | AFAIR, std::string and QString have exactly same internal unicode > | representation (UTF-16 ???). I hope so, at least (/me shrugs if they are > | different). > > They are different ... std::wstring (not std::string) is on most gcc > platforms UCS-4. (I do not know that they are different I just > assume...)
Blah. You're right. Now, the interesting thing is that wchar_t seems to be UCS-2 in linux/nls.h... argh, grepping for wchar_t in /usr/incude still requires looking at what file it's declared in ;-) Would it make any sense to use something like this: typedef uint16_t lchar_t; typedef std::basic_string<lchar_t> lstring; "l" stands for LyX (or low-overhead-in-conversion-to-QString) ;-) Somebody would have to write char_traits for lchar_t, but otherwise wouldn't it be something more-or-less useable while not requiring QString-ification of LyX sources? Now, I presume that lchar_t could be encoded in UCS-2 (is it same as UTF-16?) Cheers, Kuba Ober
