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
> 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
> 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
> 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.
Yes, but this doesn't always work (case in point with the current
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk