String literal concatenation fails when prefixed string is adjacent to non-prefixed string?

Question

In MSVS2013, which I believe to be C++11 compliant, the compiler doesn\'t like the following:

LPCTSTR str = _T(\"boo \" \"hoo\");

which transla

Answer 1

The 2003 ISO C++ standard, section 2.13.4p3, says:

In translation phase 6 (2.1), adjacent narrow string literals are concatenated and adjacent wide string literals are concatenated. If a narrow string literal token is adjacent to a wide string literal token, the behavior is undefined. Characters in concatenated strings are kept distinct.

The 2011 standard, section 2.14.5p13, says:

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.

So the sequence L"boo " "hoo" has undefined behavior in C2003 but is well defined and equivalent to L"boohoo" in C2011.

I can't tell from the information you've given us whether MSVS2013 conforms to C++11. You say it "doesn't like" the construct, but if the dislike is expressed as a non-fatal warning and the semantics are as specified in the 2011 standard, then it could be conforming.

Can you update the question to show the diagnostic message?

Answer 2

From N3797, §2.14.5/13 [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.

The table following that even lists an example that's the same as what you've shown

// Source         Means
L"a" "b"          L"ab"

So I'd say your code is well-formed and this is a VisualStudio bug.