Boost logo

Boost :

From: dmoore_at_[hidden]
Date: 2001-10-30 14:37:18

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.


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