|<<>>|269 of 274 Show listMobile Mode

Visual C++ Warning #4786

Published by marco on

Updated by marco on

The March 2002 issue of Windows Developer Journal has a tech tip that anyone who uses the STL with Visual C++ has been waiting for. If you’ve tried this, then you’ve likely gotten warning #4786, which tells you that the fully-qualified name of the class you are using is too long to fit into the debug information and will be truncated to 255 characters.

The reason behind this error is pretty stupid. You see, a while ago, I had a cross-platform project that compiled in Visual C++ 6.0 on Windows and Codewarrior 5.0 on the Macintosh. On Windows, it constantly issued this warning; but on the Macintosh, the compiler never said anything. The debug information on the Windows platform was about 600MB, while the debug information on the MacOS was about 65MB. To me, this indicated that Codewarrior was hashing the class names and using the hash key to reference the class throughout the debug information. Microsoft is likely just copying the string again and again throughout the debug information. Thus there has to be a 255 character limit in Visual C++, while CodeWarrior accepts class names of any length (it seems).

On top of the insult that the compiler tries to blame you for using class names that are too long (which just results from the insane template expansion that takes place in C++ and the STL), the error can’t even be shut off.

Until now.

Paul Hollingsworth published the following workaround (and no, I have not edited it in any way; these are his words, though they look like mine):

#pragma warning(disable: 4786)
// http://support.microsoft.com/support…
// states that yes, it's a compiler bug that
// #pragma warning(disable: 4786) doesn't always work.
 
// They don't, however, list a workaround.
 
// I found that, very strangely, #including <iostream> made the
// remaining 4786 warnings go away!
 
// Of course, #including <iostream> is inefficient and
// slows compilation − so I whittled away most of what's in
// <iostream> and discovered that the "active ingredient" in
// <iostream> appears to be a declaration of a static class,
// complete with default constructor.
 
// For some reason, this works around the bug!
// Why does this work? Beats me, ask those smart guys at MS who
// wrote the compiler.
 
class msVC6_4786WorkAround {
public:
     msVC6_4786WorkAround() {}
     };
 
static msVC6_4786WorkAround MSSucks;
 
// End of File