The new compiler error C4819

re: The new compiler error C4819

Anon — Sun, 09 Jan 2005 00:21:00 GMT

"C4819 occurs when a non-ANSI compliant compiler ignores clause 2.1 (Phases of Translation) in the C++ standard and does not map physical source characters to the basic source character set"

How does it detect invalid characters?

Michael Kaplan — Sun, 09 Jan 2005 01:35:00 GMT

Answer to the question this post implied....

re: The new compiler error C4819

Anon — Sun, 09 Jan 2005 16:03:00 GMT

Ah, it generates this when it can't perform the mapping because it has encountered a nonsense byte? That's fine, but I still think "save the file as unicode" is duff advice considering all the legacy source control systems out there...

I'm now curious. What did the compiler do prior to Whidbey? Assume a particular codepage?

re: The new compiler error C4819

Michael Kaplan — Sun, 09 Jan 2005 17:38:00 GMT

Well, the advice is for *new* code, not legacy.

Legacy systems would always save the file as ANSI and so the characters in question would be converted to question marks (same as in notepad when you try to save as ANSI).

re: The new compiler error C4819

Vladislav Vaintroub — Wed, 07 May 2008 01:05:30 GMT

Too much i18n does not seem good for the compiler.

Michael, by all respect I cannot share your view on this "incredibly cool" feature. I think it is incredibly uncool.

The bad thing about this warning can result to an error like here

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=341454

is that : C strings, the null terminated arrays of bytes,

do not have any encoding information per se, i.e are supposed to be treated as opaque arrays of bytes. Now, I have a perfectly valid

C file, containing ASCII-only, except for UTF8 bytes instrings (UTF8 for a good reason, I intend to edit this file in UTF-8 editor). And such a file will break with incomprehensible message on Whidbey on Japanese Windows now

The connect bug is now resolved with Won't Fix, so I can not even hope that this will be fixed with the next version of the compiler.

Alternatives for me?

1)Documentation and support says - add a BOM to the file. No way, then it will break on older compiler and on non-Microsoft compilers.

2)#pragma setlocale?

Does not work

3) convert strings to their hex-byte-array array form

something like

char foo={0xba,0xad,0xf0,0x0d,0x00}?

Will work, will look ugly and I'll have to forget about editing this file in a my wonderful UTF8 -capable editor , VS2005 IDE.

Or forget about getting this file compiled on Japanese Windows. It is not important *for me* anyway. This compiler works quite well on latin1 territories:)

re: The new compiler error C4819

Michael S. Kaplan — Wed, 07 May 2008 01:37:16 GMT

Since the BOM does exist, you could also petition the other compilers to start recognizing it, too. I'm sorry, but I agree with Jonathan Caves on this issue -- use the BOM and you are golden.

Everyone seems averse to the BOM these days; Should we blame TSA? :-)

Sorting it all Out — Mon, 19 May 2008 18:42:19 GMT

Sometimes things work by accident. You know -- no one ever planned for it to work, no one tested it to