Is it safe to mix UNICODE and non-UNICODE translation units?

Viewed 100

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
1 Answers

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 that tchar.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.

Related