Unicode?
Unicode?
Ok, so I guess I don't get it. Am probably missing something. I read the wiki article about unicode and can't figure out what the advantages are to "programming" in unicode (if that makes sense). What's the deal? Anyone care to shed some light on this?
Re: Unicode?
A good introduction you'll find here:
http://www.joelonsoftware.com/articles/Unicode.html
You can produce more than 256 characters. More about Unicode and PureBasic here:
http://www.xs4all.nl/~bluez/purebasic/p ... #2_unicode
http://www.joelonsoftware.com/articles/Unicode.html
You can produce more than 256 characters. More about Unicode and PureBasic here:
http://www.xs4all.nl/~bluez/purebasic/p ... #2_unicode
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Re: Unicode?
Your program can display more characters without problems. Like east european, greek, chinese, japanese, arabic, hebrew and so on.
Re: Unicode?
As far i know...
Unicode encoding is not Country related that means that every Char got its own Code...
Ascii limited and also the encoding it different in each Country ...
anyway...
datachild
Unicode encoding is not Country related that means that every Char got its own Code...
Ascii limited and also the encoding it different in each Country ...
anyway...
datachild
Re: Unicode?
so this only pertains to the way strings are handled?
Re: Unicode?
Yes.GBeebe wrote:so this only pertains to the way strings are handled?
On a related note it also determines some related things. One is the size of the data type '.c' . It's 2 bytes for Unicode and 1 for Ascii compilations. This is one reason for the types '.a' and '.u' being introduced, so that a particular character sized data type could be used that was independent of the compilation mode.
The other thing affected is API that is used by the compiled code., if the API comes in more than one flavor based on its use of strings, it will use the form that is compatible with the compilation mode. Since this is part of the compilation it happens 'under the hood' so to speak.
Re: Unicode?
And do not forget that Unicode is faster, at least on windows.
As "Wide" chars (UCS-16 LE or something actually) is the native form in Windows NT,
in particular Windows 5.x which means 2000 and XP and upwards.
If a "ASCII" program is run on Windows 5.x then the "A" function calls are redirected to the actual "W" function calls.
So there is less overhead using unicode if you plan to target 2000 and XP and later.
If you plan to target Windows 9x then you can't really use unicode.
You are also less likely to end up with garbled filenames if your program create and read files.
To put it another way, always use Unicode by default, and then only use Ascii for exe/dll's that are intended for Windows 9x.
Personally I've stopped coding for anything less than Windows 5.0
As "Wide" chars (UCS-16 LE or something actually) is the native form in Windows NT,
in particular Windows 5.x which means 2000 and XP and upwards.
If a "ASCII" program is run on Windows 5.x then the "A" function calls are redirected to the actual "W" function calls.
So there is less overhead using unicode if you plan to target 2000 and XP and later.
If you plan to target Windows 9x then you can't really use unicode.
You are also less likely to end up with garbled filenames if your program create and read files.
To put it another way, always use Unicode by default, and then only use Ascii for exe/dll's that are intended for Windows 9x.
Personally I've stopped coding for anything less than Windows 5.0