Re: Warning 4786

From: williamkempf_at_[hidden]
Date: 2001-10-30 15:38:29

--- 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.

The Boost.Threads Jam build system does not use precompiled headers, 
so this is not the culprit.

> 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)

Yes, but if the brute force disable sans push/pop doesn't work then 
the "user friendly approach" isn't going to make any difference.
 
> 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.

Yes, but this doesn't always work (case in point with the current 
Boost.Threads code).

Bill Kempf