Re: Warning 4786

From: Paul Hollingsworth (boost_at_[hidden])
Date: 2001-10-30 14:40:42

I have run into the same problem - bad STL headers doesn't explain 
everything.

However, I did find that #including <iostream> always seemed to work.

I ended up reducing it down to this header file which I include:
disable4786.h
#pragma warning(disable:4786)
// http://support.microsoft.com/support/kb/articles/Q167/3/55.ASP
// 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 
WowIWonderWhatCrapCodeMustBeInTheCompilerToMakeThisWorkaroundWork;

Hope this helps
Paul Hollingsworth
http://PaulHollingsworth.com

--- In boost_at_y..., dmoore_at_a... wrote:
> Some other ideas, since my description doesn't exactly cover the 
4786 
> case you're describing.  I was quite imprecise, as you pointed out, 
> in my first email.
> 
> 
> 1.  Warning levels and settings are compiled into the pre-compiled 
> header files, which sometimes a "Make Clean" doesn't even clear out.
> 
> 2.  The "cleanest" way to manipulate warning levels without 
> interfering with the user's command line settings is the following 
at 
> the top of your header file:
> 
> #pragma warning(push)
> // Now do your thing
> #pragma warning(disable:4786)
> 
> // Rest of header file
> 
> // And at the bottom:
> #pragma warning(pop)
> 
> 
> This may help to "tickle" the nested include bug you're running 
into 
> and get you moving down a working code path in the MS preprocessor.
> 
> 
> 3.  There's a difference between getting your headers to be "4786 
> clean" and having a library user's source code to be "4786 clean".  
> The warning is triggered whenever the template is 
> expanded/instantiated.  The technique in #2 will clean up the 
warning 
> for any member data objects contained in a class definition, but 
> wouldn't save a user from seeing the warning when they instantiate 
> something in their source code.  To help them, they need a #pragma 
> warning(disable:4786) at the top of every source file as well.
> 
> 
> 
> Dave