Home/ Questions/Q 583681
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T14:49:06+00:00

I am working on a project where I have many constant strings formed by

  • 0

I am working on a project where I have many constant strings formed by concatenation (numbers, etc.).

For example, I have a LOCATION macro that formats __FILE__ and __LINE__ into a string that I can use to know where I am in the code, when printing messages or errors:

#define _STR(x)    # x
#define STR(x)     _STR(x)
#define LOCATION __FILE__ "(" STR(__LINE__) ")"

So, this would format a location like “file.cpp(42)”. The problem is when I try to convert the result to a wide-string:

#define _WIDEN(x)  L ## x
#define WIDEN(x)   _WIDEN(x)
#define WLOCATION  WIDEN(LOCATION)

This works just fine with GCC, and results in L”file.cpp(42)” being inserted in my code. However, when trying this with MSVC++ (using Visual C++ 2008 Express), I get an error:

error: Concatenating wide "file.cpp" with narrow "("

I understand that the L prefix gets added only to the first term in my expression. I’ve also tried this:

#define _WIDEN(x) L ## #x

Which “works”, but gives the string L"\"file.cpp\" \"(\" \"42\" \")\"" which is obviously not very convenient (and not what I am looking for), especially considering that this macro is simple compared to other macros.

So, my question is: how can I get it to apply to the entire expression in MSVC++, so I can get the same result I am getting with GCC? I would rather not create a second string with all-wide tokens, because I would then have to maintain two macros for each one, which is not very convenient and can lead to bugs. Plus, I need the narrow version of each string as well, so using all-wide strings is not an option either, unfortunately.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    According to the C standard (aka “ISO-9899:1999” aka “C99”), Visual C is wrong and gcc is correct. That standard states, section 6.4.5/4:

    In translation phase 6, the multibyte character sequences specified by any sequence of adjacent character and wide string literal tokens are concatenated into a single multibyte character sequence. If any of the tokens are wide string literal tokens, the resulting multibyte character sequence is treated as a wide string literal; otherwise, it is treated as a character string literal.

    So you could file a complaint. Arguably, the previous version of the C standard (aka “C89” aka “C90” aka “ANSI C”) did not mandate merging of wide strings with non-wide strings. Although C99 is now more than ten years old, it seems that Microsoft has no interest in making its C compiler conforming. Some users have reported being able to access some “C99” features by compiling C code as if it was C++ code, because C++ includes these features — and for C++, Microsoft made an effort. But this does not seem to extend to the preprocessor.

    In the C89 dialect, I think that what you are looking for is not possible (actually I am pretty sure of it, and since I have written my own preprocessor I think I know what I am talking about). But you could add an extra parameter and propagate it:

    #define W(x)          W_(x)
#define W_(x)         L ## x
#define N(x)          x
#define STR(x, t)     STR_(x, t)
#define STR_(x, t)    t(#x)

#define LOCATION_(t)  t(__FILE__) t("(") STR(__LINE__, t) t(")")
#define LOCATION      LOCATION_(N)
#define WLOCATION     LOCATION_(W)

    which should work on both gcc and Visual C (at least, it works for me, using Visual C 2005).

    Side note: you should not define macros with a name beginning with an underscore. These names are reserved, so by using them you could clash with some names used in system headers or in future versions of the compiler. Instead of _WIDEN, use WIDEN_.

    • 0