Unicode Basics on Windows

Hello,

I have a C++ library which I deliver to other developers. One of them needs i18n, so he asked me if I could add L prefix to the strings in the API.

I don't know much about i18n so I have some basic questions:

1. When I compile my lib with Unicode, can other developers use this build as usual ? Or shall developers also change their Visual Studio settings to use unicode ?

2. When I compile my lib with Unicode, do I need to change all the strings in headers and .cpp files? Or is it sufficient to add L prefix to strings in header files ?

Thanks in advance!

Paul

From stackoverflow

• There's a lot more than Unicode support to internationalization (i18n). Off the top of my head, there is:

  • Currency
  • Number representation
  • Text encodings (partially abstracted by the use of Unicode)
  • Right-to-left scripts
  • Text translation mechanisms

  Most of this is available in some form or another through APis on Window, whether it be Win32 or .Net, etc. I suggest you take a look at:

  • Microsoft .Net Internationalization
  • The Microsoft Win32 Internationalization Checklist

• Adding the L prefix changes the string from a char array into a short array. A better alternative is to wrap all your strings with the "TEXT" macro, i.e.

  TEXT("My string")
  

  If your build is a Unicode build, all your strings become an array of shorts, but if not, they remain as an array of chars. Windows also provides the following types:

  LPWSTR = short *
  
  LPTSTR = short *, or char * if UNICODE not defined
  
  LPSTR = char *
  

  Don't forget though; even though you've prefixed L or wrapped TEXT to your strings, you need to make sure you're calling the right functions. Standard Windows string API such as lstrlen automatically switch from char * to short * if UNICODE is defined, but you'll need to make sure you're not using functions that only use char *.

  Functions that your library exports that use strings will also break older applications that use your library since those applications will still be passing and array of chars rather than shorts, so you'll probably want to work in some sort of backwards compatibility in there.

  Éric Malenfant : The L prefix makes the string a wchar_t array, not short. The confusion probably comes from the fact that, in the old MSVC6, wchar_t was not a native type, but only a typedef for short (or was it unsigned short?)

  dreamlax : wchar_t is still a typedef for unsigned short in MSVC 2008. Look at crtdefs.h.

  Ismael : There's a compiler options which turn wchar_t in a basic type, http://msdn.microsoft.com/en-us/library/dh8che7s(VS.71).aspx, if I'm not wrong this is the default setting since VS 2005.