Re: Warning 4786

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.

Dave