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