How make a preprocessor string that work with both narrow and wide

Question

I have to make two projects with different names. Both projects will share the same code.

So I started replacing the places that call the old name to a preprocessor in stdafx.h called APP_NAME

In stdafx.h I put

#define APP_NAME _T("My name") 

And when I find code like

function(parm1,_T("My old name have a error"));

I want to replace with

function(parm1, APP_NAME _T(" have a error"));

But, a lot of errors appear when mixing wide ( T("x") or L"") with pure narrow ("")

error C2308: concatenating mismatched strings

Is it possible to do any preprocessor magic to overcome it?

Answer 1

Perhaps the problem is that you define a macro APP_NAME but then use NAME later. If that is not the real problem, then you simply need to consistently use _T("...") so that all strings will be prefixed correctly (and assuming _T expands to nothing more than a wide or narrow qualified string in your environment).

Answer 2

Move the _T to where the macro is used, because that's where the correct encoding is known.

#define APP_NAME "My name"
function(parm1, _T(APP_NAME) _T(" have a error"));

---

But you shouldn't actually have to, this is a bug in Visual C++ 2010. C++0x requires that (section [lex.string]):

In translation phase 6 (2.2), adjacent string literals are concatenated. If both string literals have the same encoding-prefix, the resulting concatenated string literal has that encoding-prefix. If one string literal has no encoding-prefix, it is treated as a string literal of the same encoding-prefix as the other operand. If a UTF-8 string literal token is adjacent to a wide string literal token, the program is ill-formed. Any other concatenations are conditionally supported with implementation-defined behavior. [ Note: This concatena- tion is an interpretation, not a conversion. Because the interpretation happens in translation phase 6 (after each character from a literal has been translated into a value from the appropriate character set), a string literal’s initial rawness has no effect on the interpretation or well-formedness of the concatenation. — end note ]