0

I have Microsoft C++ compiler experience. There you could adjust your using/not using UNICODE compilation path very simply. Following constructions were legitimate and perfectly possible:

#ifdef UNICODE
typedef std::wstring string;
#else
typedef std::string string;
#endif

But how can I handle the same situation with Apple LLVM compiler?

P.S. GCC hints will also be appreciated.

UPDATE: In Windows programming it is better to use UNICODE strings (especially, if you heavily work with WinAPI, which is UNICODE based). Are there any reasons to use wstring instead of string (except charset differences) on LLVM or GCC for OSX and iOS?

Kara
  • 6,115
  • 16
  • 50
  • 57
nickolay
  • 3,643
  • 3
  • 32
  • 40

1 Answers1

2

It's arguable that you should even care about supporting multiple types of strings (it depends on the application), but perhaps the following should work:

#if defined(_WIN32) && defined(UNICODE)
    typedef std::wstring string;
#else
    typedef std::string string;
#endif

Also, read the following post to learn all about the different types of strings and their use cases: std::wstring VS std::string

Community
  • 1
  • 1
Chad Seibert
  • 31
  • 1
  • Very nice answer. Thank you. Could you be so kind to extend your answer a bit and tell me in a concise manner whether I should even worry of using wide strings on OS X (and iOS)? Or std::string will be sufficient to use any of OS X Core Foundations APIs? Thanks! – nickolay May 17 '13 at 12:23
  • I'm not an OS X expert, so I could be completely off base here, but I'd say no. There are very few reasons to use wstring's. In fact, your probably better off only using std::string's and converting to unicode when necessary. – Chad Seibert May 17 '13 at 12:33
  • Concerning WinAPI based application it's very inconvenient to use std::string because you'll loose on conversions (UNICODE <-> ANSI) which happen very often. Of course, you can use ANSI aliases of WinAPI functions but they are only macroses which implicitly convert your ANSI encoded arguments to UNICODE ones and call "real" API code that is ALL UNICODE based (refer to J.Richter "Programming Windows" 5th ed.). – nickolay May 17 '13 at 15:49
  • I meant in the case of needing Unicode strings on OSX. What I said about Win32 still stands (and is confirmed by the link I mentioned earlier). – Chad Seibert May 17 '13 at 17:45
  • Okay. I just added my experience that made a habit to think about UNICODE/not-UNICODE. Thanks again! – nickolay May 18 '13 at 08:36