Which statements are correct?
-
Hi, I have an old ANSI VC++ dialog based application which I would like to make it UNICODE enabled application. So I started converting all "char" types to "TCHAR" types. Howerever there is a certain piece of code that is sort of hardwired with statements like const char cEscape = -16; If I convert it to TCHAR equivalent and compile and execute const TCHAR cEscape = (const TCHAR)-16; the value of the cEscape variable (as seen in quickwatch window in VC++ debugger) is 65520 I am wondering should the value of the cEscape variable be 240 which is unsinged char equivalent of signed char -16 or the value 65520 is correct? Can someone please clarify? Thanks and Regards :)
-
Hi, I have an old ANSI VC++ dialog based application which I would like to make it UNICODE enabled application. So I started converting all "char" types to "TCHAR" types. Howerever there is a certain piece of code that is sort of hardwired with statements like const char cEscape = -16; If I convert it to TCHAR equivalent and compile and execute const TCHAR cEscape = (const TCHAR)-16; the value of the cEscape variable (as seen in quickwatch window in VC++ debugger) is 65520 I am wondering should the value of the cEscape variable be 240 which is unsinged char equivalent of signed char -16 or the value 65520 is correct? Can someone please clarify? Thanks and Regards :)
How about const TCHAR cEscape = _T('\xF0'); That keeps the value -16 (240 unsigned) and it's generic/portable. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
How about const TCHAR cEscape = _T('\xF0'); That keeps the value -16 (240 unsigned) and it's generic/portable. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Thanks though I think my question is still unanswered. If the value of cEscape should be 240 (_T('\xF0') then could there be a reason that the VC++ 2005 compiler is evaluting it to 65520 and not 240 ! I have checked the disassembly and it shows that the compiler is assigning 0xFFF0 to the cEscape variable and not 0x00F0. Regards.
-
Thanks though I think my question is still unanswered. If the value of cEscape should be 240 (_T('\xF0') then could there be a reason that the VC++ 2005 compiler is evaluting it to 65520 and not 240 ! I have checked the disassembly and it shows that the compiler is assigning 0xFFF0 to the cEscape variable and not 0x00F0. Regards.
psychedelic_fur wrote:
could there be a reason that the VC++ 2005 compiler is evaluting it to 65520 and not 240
Yes. I tested this (note I'm using VC++ 2005 SP2 compiler): const TCHAR cEscape = _T('\xF0'); TCHAR s[10]; s[0] = cEscape; My compiler settings have "Treat wchar_t as Built-in Type" set to "Yes". cEscape is 240 as expected. If that setting isn't enabled, then the result may be different. If wchar_t is treated as a signed short int then the the entire value gets treated as negative. Not good. I suppose you can try this (preferred): const TCHAR cEscape = _T('\x00F0'); or mask off the high byte (lame but works) const TCHAR cEscape = _T('\xF0') & 0x00FF; Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Hi, I have an old ANSI VC++ dialog based application which I would like to make it UNICODE enabled application. So I started converting all "char" types to "TCHAR" types. Howerever there is a certain piece of code that is sort of hardwired with statements like const char cEscape = -16; If I convert it to TCHAR equivalent and compile and execute const TCHAR cEscape = (const TCHAR)-16; the value of the cEscape variable (as seen in quickwatch window in VC++ debugger) is 65520 I am wondering should the value of the cEscape variable be 240 which is unsinged char equivalent of signed char -16 or the value 65520 is correct? Can someone please clarify? Thanks and Regards :)
The C++ standard does not dictate whether
charis signed or unsigned. The default forcharin Visual C++ is signed (but this can be changed with a compiler option).wchar_tis a typedef forunsigned shortin older compilers and so is always unsigned. This sounds like a value that is not used as a character, only as an 8-bit integer, and you should leave it ascharrather than blindly converting toTCHAR. You should evaluate all uses ofcharcarefully as it sounds like a codebase where aBYTEtypedef was not used.
DoEvents: Generating unexpected recursion since 1991