There's a class of tools that lots of people write that replace cl.exe with a 'wrapper' to do things link pre-process a command line [perhaps adding particular -D arguments], or filtering the output to deal with things like psychotically complicated error messages from template metaprogramming. These tools tend to be incredibly useful, and also tend to be incredibly straightforward to author. And with VS2005, they tend to be broken when running under the IDE. With 2005, the compiler toolset finally got serious about supporting Unicode. You can write code in Unicode (so you can have variable names like "a picture of a telephone" :-) ) You should also get your error messages in Unicode. The trouble arises when you realize the ethnocentric history of software. It's the stomping ground of the English-speaking white male. I'm not trying to be rude, racist, sexist, or generally offensive, I'm just speaking historically (and unfortunately, it continues to be a field dominated by men, though the few women I have been able to work with are truly brilliant). Whoops - get off that tangent and back to the point... The Win32 console file handles cannot handle Unicode. They're code-page based handles, so when you're running under the console, we just spit out code-page based errors & warnings. If those errors & warnings contain Unicode, you're just out of luck. Well, when cl.exe is running under the IDE, we figured we could improve the experience. Instead of spitting messages out stdout and stderr, we open up some named pipes, and spit out Unicode that the IDE can then display. Which is great, until you start thinking about the cl.exe proxy scenario. So, if you're writing a cl.exe proxy, prior to invoking the original cl.exe, undefine VS_UNICODE_OUTPUT. This successfully tricks cl.exe into thinking you're just compiling from the command line, and you're back in business (with non-Unicode messages, though :-( )
Update: Leor Zolman (Mr. STLFilt himself!) mentioned he couldn't get this working. Turns out there's one more little issue that you may not realize: The response files being fed to cl.exe are probably unicode. You have to uncheck that, or else handle unicode response files for everything to work properly. If you turn off 'Use Unicode Response Files" in your project, go grab the source to STLFilt and change the doWin32Stuff function to have this at the beginning:
// from cl.cpp:
int doWin32Stuff(char *full_filt_cmd, char *cmdline)
using namespace std;
log("VS_UNICODE_OUTPUT is enabled - disabling!");
// Clear the Unicode output flag to force the compiler to use the normal output pipes
// I don't know perl at all, but this is how you do it from C:
Hmm, well, in SP1 can we have a new environment variable?
Perhaps: VS_ANSI_OUTPUT, which would of course, override the unicode one.
PingBack from http://blog.assarbad.net/20070103/memo-to-self-vs_unicode_output/
LOL, just happened upon this page while diddling with Google.
And I STILL have no idea how to get this to work in STLFilt myself.
In case anyone's figured it out, please let me know! (Contact info at my web site...)