混合使用 UNICODE 和非 UNICODE 翻译单元是否安全？

Question

I'm integrating a library which requires _UNICODE and UNICODE to be defined; I can't set these definitions globally on my project for now, so I was wondering if I can safely build only the library code with these definitions.

I'm worried about ODR violations, but as far as I understand these definitions only impact macro definitions in the Windows and C runtime headers, so I would expect no ODR violations (as long as my own headers shared between translation units don't depend on UNICODE ), but is it really a guarantee?

Is it safe to mix translation units built with and without UNICODE / _UNICODE ?

In other words, is it safe to compile these two files into the same binary:

// a.cpp
#define _UNICODE
#define UNICODE
#include <tchar.h>
// maybe other windows header inclusion
// some code

---

// b.cpp
//#define _UNICODE
//#define UNICODE
#include <tchar.h>
// maybe other windows header inclusion
// some other code

Answer 1

If there is one inline function with _TEXT() / TCHAR /... in different translation unit, one with preprocessor defined and one not (even if function is not used), then you got ODR -violation.

"is it safe?"

No.

Do you have currently ODR violations?

Not sure, maybe, maybe not.

Currently thattchar.h only #define / typedef some aliases. so doesn't do ODR-violation by itself.

Can Microsoft change <tchar.h> or other windows headers in a way it might produce ODR violation for your code?

Yes.

Would they do it?

Maybe, maybe not.

Answer 2

You can mix UNICODE and non-UNICODE compiles when there are no typedef , for example if tchar.h is not included.

Otherwise UNICODE will just determine the macro translation of SetWindowText , and other APIs and macros. It is possible to combine Unicode and ANSI, but it's confusing.

Note that in a single function, it is valid to call both SetWindowTextA(hwnd, "ansi") and SetWindowTextW(hwnd, L"unicode") . You can compile the project as Unicode and use the ANSI APIs for optional interface.