Joe Woodbury wrote:"Hello World" is an ANSI string, even in a application build with UNICODE libraries.
L"Hello World" is the UNICODE string in either environment.
I wouldn't expect anyone reasonable to define strings like this, unless for a debate. My point was that he should not be including ANSI stuff into an Unicode application (why not Unicode?), as that might bring down the performance.
I assume the usage of generic text mapping routines and I could have specified it clearly. Does my comment make sense if string literals enclosed within the TEXT macro?
Rajesh R Subramanian wrote:
Also, if you write an application in ANSI, Windows will still have to convert everything to Unicode internally to work with it. So, theoretically your application must be faster if it is built for Unicode.
Joe Woodbury wrote:Even the underlying API has both Wide and Ansi versions. Sometimes the strings in these are converted. Other times they are not.
It wasn't clear enough that I told "Windows" and not APIs? An API may have both versions, but when it has to pass on a string to Windows, it must be converted to Unicode. Even if a function returns an ANSI string, again, Windows actually returns a Unicode string and there happens another conversion which is not visible to the user calling the API and essentially the performance goes down.
It is a crappy thing, but it's life -^ Carlo Pallini
modified on Sunday, May 17, 2009 2:40 AM