NO

Author Topic: UNICODE - String format specifier %ls and %s  (Read 9127 times)

JohnF

  • Guest
UNICODE - String format specifier %ls and %s
« on: August 31, 2007, 03:12:58 PM »
How to arrange code so that it will use either %ls or %s depending on weather UNICODE is defined or not?

#include <tchar.h>
_stprintf(str, num, _T("%s%s"), str1, str0);

In the above call "%s%s" is ok when UNICODE is not defined but will not work when UNICODE is defined, it needs to be "%ls%ls".

Obviously I don't want to have #ifdef guards all through the code.

John


severach

  • Guest
Re: UNICODE - String format specifier %ls and %s
« Reply #1 on: September 02, 2007, 06:58:34 AM »
http://www.smorgasbordet.com/forum/index.php?topic=1627

I've asked for this to be fixed already. A really messy solution I've used is #defines.

Code: [Select]
#ifdef __POCC__
#ifdef UNICODE
#define TS "%ls"
#else
#define TS "%hs"
#endif
#else
#define TS "%s"
#endif

_tprintf( _T(TS TS),_T("TString"),_T("TString"));

Since that is so unreadable and unmaintainable the method I actually use is to never use Pelles-C for production UNICODE code.

JohnF

  • Guest
Re: UNICODE - String format specifier %ls and %s
« Reply #2 on: September 02, 2007, 08:07:31 AM »
The problem is that the C Standard specifies %ls and PellesC conforms to the standard. Microsoft allows just %s

edit:
It's unfortunate that tchar.h jumps through hoops to allow dual compilation but the %ls specifier spoils it.

John
« Last Edit: September 02, 2007, 10:05:25 AM by JohnF »

severach

  • Guest
Re: UNICODE - String format specifier %ls and %s
« Reply #3 on: December 09, 2007, 11:13:31 PM »
The really messy problem is that the standard as written before my complaints to Pelles and Watcom was ambiguous which allowed the other compiler writers to interpret %s==TCHAR, the most desirable and least obfuscated method for Windows TCHAR development. The standard was clarified shortly after to say %s==8-bit char which is hostile to Windows TCHAR development but it does say the Pelles implementation is according to the standard and the other compilers are not. This puts compilers in two camps with incompatible handling of %s and neither side can change because of the compatibility problems that would arise and neither side wants to change because there is or was a standard that said the chosen method was right. This means that for the foreseeable future Pelles %s handling will be incompatible with MSVC unless you make Pelles link those functions against MSVCRT.DLL.

Since this problem looks like it won't be going away I've had to revise my macros that adapt %s to the correct width depending on the compile and compiler. These macros don't handle the case where Pelles is linked to Microsoft LIBS like MSVCRT.DLL.
Code: [Select]
  #define W_pch "lc"
  #define W_pst "ls"
  #ifdef __POCC__
    #define A_pch "c"
    #define A_pst "s"
    #ifdef UNICODE
      #define T_pst W_pst
      #define T_pch W_pch
    #else
      #define T_pst A_pst
      #define T_pch A_pch
    #endif
  #else
    #define A_pch "hc"
    #define A_pst "hs"
    #define T_pst "s"
    #define T_pch "c"
  #endif
// TCHAR test[256]; _sntprintf(test,NELEM(test),_T("%") A_pst _T("%") W_pst _T("%") T_pst,"char",L"wchar",_T("tchar"));