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 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.
Related
I'm experimenting with header units. Currently, I'm testing in Visual Studio 2022(Version 17.2.3).
I'm currently importing multiple header units, for example
import <windows.h>;
import <thread>;
warning warning C4005: '__analysis_assume': macro redefinition 1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\shared\specstrings_strict.h(933): message : see previous definition of '__analysis_assume'
It kind of make senses because if <thread> and <windows.h> have any shared headers normally the inclusion guards or pragma once would prevent them from being included and being multiply defined.
I'm not really sure how header units can work if they shared header files with macros which a majority of header files of external libraries use.
I'm sure I can ignore the warning but I'm curious if anyone else has a better solution.
It seems this is a known issue with import causing multiple macro redefinitions when using windows.h.
https://developercommunity.visualstudio.com/t/warning-C4005:-Outptr:-macro-redefinit/1546919
We will have to wait for Microsoft to address this issue.
I'm trying to track down the source of this large warning in a big code base:
C:\Program Files (x86)\Microsoft Visual Studio 12.\VC\INCLUDE\xmemory0(592) :
warning C4503:
'std::_Tree<std::_Tmap_traits<_Kty,_Ty,_Pr,_Alloc,false>>::_Insert_at' : decorated name length exceeded, name was truncated
with
[
_Kty=epmem_node_id,
_Ty=std::map<std::string,std::list<std::string,std::allocator<std::string>>,std::less<std::string>,std::allocator<std::pair<const std::string,std::list<std::string,std::allocator<std::string>>>>>,
_Pr=std::less<epmem_node_id>,
_Alloc=std::allocator<std::pair<const epmem_node_id,std::map<std::string,std::list<std::string,std::allocator<std::string>>,std::less<std::string>, std::allocator<std::pair<const std::string,std::list<std::string,std::allocator<std::string>>>>>>>
]
I am planning on putting in the following to silence it:
#pragma warning(push)
#pragma warning(disable:4503)
... code here
#pragma warning(pop)
However, I keep putting this in the code base and the warning still pops up. The warning, unfortunately, does not specify what line, file or even class or variable the problem is found in, so I am completely lost. I tried using dumpbin /ALL, but when I searched the file I did not find _Tree anywhere.
How can I locate the source of this warning in my code base?
My question was how to find which line of code is causing the problem, but that wouldn't actually solve my problem. Since the offending code involves templating, the decorated name which cl warns about is generated after the rest of the code in the translation unit is processed, and so I would not be able to surround any given piece of code with a warnings(push)/warning(pop) pair.
The solution for me was to put #pragma warning(disable:4503) at the end of the file (I put it just before the #endif of the include guard). This silences the warning for all decorated names generated from structures in the file which use tempaltes. The scope of a warning(...) pragma is just to the current translation unit, so this doesn't affect any other files.
In my C++ project, I use precompiled headers as a compile time optimization. However, when I enable /Wall option in the compiler settings, I am not able to suppress any of warnings in the precompiled header file.
Header File:
#ifndef _PRECOMPILED_H
#define _PRECOMPILED_H
#pragma warning(push, 0)
#pragma warning(disable: 4514)
#include <vector>
#pragma warning(pop)
#endif /* _PRECOMPILED_H */
Source File:
#include "precompiled.h"
I end up with tons of warnings in vector.
When I do the same, but in a regular file, everything works as expected.
Any solutions for this problem?
I am using Visual Studio 2013 community edition update 4.
Don't use /Wall with Visual C++. It doesn't mean the same as -Wall with g++. Use /W4 (rough equivalence with g++ -Wall).
I did not get a 4514 warning from including vector.
You have only disabled 4514, and only in the vector header. I think this is happening in other code that happens to use vector, and the warning message (which you did not post) refers to the vector header since that's where the function being removed by the optimizer was declared.
I'm trying to convert a project from VS2008 to VS2013 and one (of the many) problem's I have encountered is this:
c:\program files (x86)\microsoft visual studio 12.0\vc\atlmfc\include\atlbase.h(4953): error C3861: '_beginthreadex': identifier not found
I've searched the net for a solution, I have already include process.h in my StdAfx.h, (not sure if it matters, but I placed it below the #include and #include or else I receive a "Windows.h" already included error).
I am using MFC as shared dll, I am compiling with /MDd and checked that -D_MT flag is on.
(I am also not doing #undef _MT in my code).
How can I solve this issue?
I found out what the problem was. I had a different "process.h" file in one of the additional include directories, after adding "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include" first in the additional include directories the problem was solved.
You need:
#include <crtdefs.h>
#include <process.h>
crtdefs.h will define/undefine _CRT_USE_WINAPI_FAMILY_DESKTOP_APP which _beginthreadex is wrapped in within process.h.
You have to include process.h to get access to this function.
Inside of an MFC application you should use AfxBeginThread.
#include <iostream>
int main()
{
int value1 = 1, value2 = 10;
std::cout << "Min = " << std::min(value1,value2) <<std::endl;
std::cout << "Max = " << std::max(value1,value2)<< std::endl;
}
As far as I know, the min and max functions are defined in <algorithm>.
If I didn't tell the pre-processor to include <algorithm> why does the code still work?
Most likely, something inside of iostream has directly or indirectly included some other header that defines std::min and std::max. (Perhaps algorithm itself has been included. Perhaps some internal header that is used to implement your C++ standard library.)
You should not rely on this behavior. Include algorithm if you want std::min and std::max.
If you are used to a language with a module system where modules can import other modules and not be forced to export anything from their imports (e.g., Racket's module system), this behavior can be confusing.
Recall, however, that #include is doing textual substitution. When the #include line is processed, it is removed from the .cpp file and replaced with the contents of the file it was pointing to.
Most compilers have an option to dump the output of running the preprocessor so you can track down what is including what. You said in your comment to kmort's answer that you are using Visual Studio Express. The command line to preprocess a file to a file using the Visual C++ compiler is cl /P foo.cpp. Using this output, we can find that the definition of std::max is coming from the implementation-specific header xutility. (Placing the caret inside of the text "std:max" and pressing F12 in Visual Studio is even faster. :-] )
kmort also mentioned the /showIncludes compiler switch. Using that, we can easily track down the include chain. Here's the reduced output from my run.
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\iostream
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\istream
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\ostream
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\ios
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xlocnum
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\streambuf
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xiosbase
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xlocale
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\stdexcept
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xstring
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xmemory0
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\xutility
What compiler are you using?
I have seen compilers before that are somewhat "forgiving" for common items that are defined in libc or libstdc++. It will pull in the references for you. In other words, you don't have to tell it to link with it, nor include the header. It just works. While I would not have expected this of min() and max(), it's not too surprising.
This can also happen by some other header including the one you should be including, but this should not be relied on. And I don't expect it to have happened in this case.
Just to add the above conversations, I stumbled across a similar issue recently. If you execute the min/max calls without including the algorithm header, it'll still run fine.
std::min(value1, value2)
But if you execute it over an initializer list (put all variables in between {...}) like below,
std::min({value1, value2, value3})
the compiler throws an argument mismatch error. This might most likely be because the function overriding couldn't catch template constexpr T max (initializer_list il, Compare comp) which must only be defined inside algorithm.h. As others have answered, the basic template constexpr const T& max (const T& a, const T& b) could've been included somewhere inside of iostream. But I don't think the whole algorithm header file was included because if it was, the above snippet should've worked too.