Mike wrote: > Surely using a different type on different platforms means that we throw > away the concept of a platform independent Unicode string? > I.e. on Solaris, wchar_t is 32 bits, on Windows it is 16 bits. so? the interchange format doesn't have to be the same as the internal format, does it? > Does this mean that to transfer a file between a Windows box and Solaris, an > implicit conversion has to be done to go from 16 bits to 32 bits (and vice > versa)? What about byte ordering issues? no problem at all: unicode has special byte order marks for this purpose (and utf-8 doesn't care, of course). > Or do you mean whatever 16 bit data type is available on the platform, with > a standard (platform independent) byte ordering maintained? well, my preference is a 16-bit data type in the plat- form's native byte order (exactly how it's done in the unicode module -- for the moment, it can use the platform's wchar_t, but only if it happens to be a 16-bit unsigned type). gives you good performance, compact storage, and cleanest possible code. ... anyway, I think it would help the discussion a little bit if people looked at (and played with) the existing code base. at least that'll change arguments like "but then we have to implement that" to "but then we have to maintain that code" ;-) </F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4