2

What's the difference between me explicitly defining every Win32 API I use in my project as W (Wide) or A (ANSI) and letting it be decided by the solution/project configuration? Apart by being able to change it on the fly, that is.

Say I only need Unicode at the moment for some reason, would it be better of me to just let them expand to the correct one automatically or explicitly define them? Would it break some systems on release if I only develop for ANSI or Unicode versus supporting both?

Banderi
  • 656
  • 3
  • 7
  • 29
  • 2
    If, for some reason, Microsoft decides to use UTF32 instead of UTF16 and deprecate the wide-character functions, if you have been using the aliases and the `T`-family macros, then all you need to do is a recompilation and it should (hopefully) work out just fine. If you use the functions directly you have a lot more work to do. It's a highly unlikely scenario, but the only one I can imagine at the top of my head at the moment. – Some programmer dude Apr 04 '16 at 06:32
  • 3
    The advantage of using Unicode types and functions rather than the macros is that your code is clearer. You aren't going to support Windows 98 so why write code to do so. You'll never compile without Unicode support. Keep life simple and avoid needless indirection. – David Heffernan Apr 04 '16 at 06:42
  • 1
    @DavidHeffernan: Generic text mappings are really more than just an archaic leftover from the past. They serve as a switch that can be controlled externally. Unlikely as it may be, Joachim's comment outlined one scenario, where the generic text mappings could be the right way moving forward. – IInspectable Apr 04 '16 at 09:15
  • @IInspectable In my opinion, they are an archaic leftover from the past. – David Heffernan Apr 04 '16 at 09:16
  • @DavidHeffernan: Stating your opinion without a rationale is not very helpful. Your opinion may or may not be justified. Without understanding, how you arrived at that conclusion, it is difficult to draw any value from it, though. – IInspectable Apr 04 '16 at 09:21
  • @DavidHeffernan If I undertand correctly, I'd argue ANSI/ASCII would be an archaic leftover from the past, while generic text mappings are generally not. – Banderi Apr 04 '16 at 09:22
  • @IInspectable The rationale is that the likelihood of Win32 ever being anything other than a UTF-16 API is vanishingly small. – David Heffernan Apr 04 '16 at 09:26
  • @Banderi What is the point of generic text mappings and indirection that always map to Unicode? Why obfuscate? What is the benefit of making your code harder to understand and harder to write? – David Heffernan Apr 04 '16 at 09:27
  • @DavidHeffernan Well, I intended it as a general notion for flexibility, not in this specific situation; after all, "generic text mappings" sounds pretty generic to me. Of course Unicode is indeed the option to follow since in this specific case it will alias to it anyways 99.9% of the time. – Banderi Apr 04 '16 at 09:42
  • 1
    It might be relevant to point out that an increasing number of functions do not have *A/*W variants anymore. There's just one version, and it takes WCHAR. – MSalters Apr 05 '16 at 07:31

2 Answers2

3

The last versions of Windows that were based on an "ANSI" charset (Windows 9x) reached end of life long ago. All newer versions (based on NT), even the embedded ones, use UTF-16 to provide full Unicode support. For those, all the ANSI functions are implemented as wrappers which cause overhead (conversion needs time and space) and loss of data (ANSI is only a subset of Unicode).

I would only use the wide versions. In particular, when exporting interfaces, I would refrain from using TCHAR-based strings, because it would require me to provide two different implementations and because it shouldn't be necessary for modern code.

Ulrich Eckhardt
  • 16,572
  • 3
  • 28
  • 55
1

Main reason why you should prefer W variants is that A-calls are unreliable when you deal with strings - they always imply implicit codepage, which is variable. So program behavior depends on a system settings, which is never good. Chances of them redefining TCHAR in future are very close to zero - there's no technical advantage in this change, and it will break a lot of things, so worrying about that makes no sense.

bunglehead
  • 1,104
  • 1
  • 14
  • 22