开发者

How can I identify the header that generates a warning?

I'm sure that many of you are familiar with this set of warnings. These are most of the time generated by a include file. Solution is pragma push/disable/pop, but identifying the header is not a nice task.

Does anyone knows a way of identifying the header except trial-and-error ?

1>File1.cpp
1>C:\Program Files (x86)\Microsoft Visual开发者_JS百科 Studio 9.0\VC\include\cstdio(49) : warning C4995: 'gets': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstdio(53) : warning C4995: 'sprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstdio(56) : warning C4995: 'vsprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstring(22) : warning C4995: 'strcat': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstring(23) : warning C4995: 'strcpy': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cwchar(36) : warning C4995: 'swprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cwchar(37) : warning C4995: 'vswprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cwchar(39) : warning C4995: 'wcscat': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cwchar(41) : warning C4995: 'wcscpy': name was marked as #pragma deprecated
1>Linking...


In my case, moving #include <strsafe.h> to the bottom of the list got rid of the warning without using extra compiler directives.

A good way to find out where #pragma deprecated was being called was to go into the compiler settings under "Preprocessor" and to set Generate Preprocessed File to something like With Line Numbers (/P). Rebuild, then open up the *.i file and search for deprecated. Nearby will be the name of the offending include.

I'm using VS2003, so the dialogs may be slightly different for you.


The standard include files should have include guards. So you may be able to explicitly include those files at the top of your own file, with that warning disabled:

#pragma warning(push)
#pragma warning(disable: 4995)
#include <cstdio>
#include <cstring>
#include <cwchar>
#pragma warning(pop)

// rest of your #includes

That way the warnings will be disabled for the headers where you know there are problems. This needs to be at the top of your code so the headers are included for the first time inside the warning-disabled section.


I would like to second what @Celdecea said.

Clearly it would be nice if MS did what GCC does and specified the included path (stack?) for the file, which I presume is what you were looking for; unfortunately, I was unable to find a compiler directive to do that, so grepping through the .i file was a painful but effective replacement.

I too found that my problem stemmed from adding #includes after <strsafe.h>. Since my error list was (almost?) identical to yours I wouldn't be surprised if that also solves your problem.

If not, or if you wish to employ the pragma push/disable/pop style, then it seems that @Greg has the best solution in preemptively and explicitly defining those headers that are causing you pain.


The notes for #include strsafe.h include the line:

To use the Strsafe functions inline, include the header file as shown here, following the #include statements for all other header files.

In the MSDN offline help it says:

Important: The include line for strsafe.h should follow all other headers' include lines.

Make sure that you've only included in cpp files and after all other c++ library header files and the warnings goes away.

Kevin


To add to Greg Hewgill's post, I found the problem in set and I did not suspect this file.

#pragma warning(push)
#pragma warning(disable: 4995)
#include <set>
#pragma warning(pop)

Doing the above solved my problem.


In Visual Studio 2010 (and probably other versions too) set the C++/advanced 'show includes' option to Yes or add the /showIncludes command line option.

Then compile one file at a time and search the build output window for the warning number that you're looking for and it will show the tree of include files that is generating that warning.

This technique is useful for most build problems caused by include files.

EDIT: make sure you turn off /showIncludes when the problem is fixed as it can interfere with other compiler options (e.g. /MP (Build with Multiple Processes) is disabled).

To suppress the warning add the offending include files to a 4995 suppression block as suggested by Greg Hewgill above. This can either be at the top of the source file or in a precompiled header or in a 'forced' include file included across the project (C++/Advanced/Forced Include File).

The particular problem with 4995 CRT deprecation errors is that they seem to be generated every time code calls deprecated functions even if warning 4995 was suppressed when the deprecated functions were declared.


In my case for VS2008 these warnings were coming from #include <vector> (or some other std library.) It seems like Microsoft can't follow their own advice.

Doing the following fixed the issue:

#pragma warning(push)
#pragma warning(disable: 4995)
#include <vector>
#pragma warning(pop)

Just make sure that you do it as early as possible in your includes.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜