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