Boost logo

Boost :

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

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

I ended up reducing it down to this header file which I include:
#pragma warning(disable:4786)
// states that yes, it's a compiler bug that #pragma warning(disable:
// 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
// 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
// compiler.
class msVC6_4786WorkAround {
        msVC6_4786WorkAround() {}

static msVC6_4786WorkAround

Hope this helps
Paul Hollingsworth

--- In boost_at_y..., dmoore_at_a... wrote:
> Some other ideas, since my description doesn't exactly cover the
> 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
> 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
> 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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at