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.
Related
Trying to fix the following "macro redefinition" warning:
1>Path\to\MKL\include\math.h(1577): warning C4005: 'HUGE_VALF' : macro redefinition
1> Path\to\Microsoft Visual Studio 12.0\VC\include\../../vc/include/math.h(104) : see previous definition of 'HUGE_VALF'
Generated from this code:
#include "ABC/CUDA_FFT.h"
#include "ABC/logging.h"
#include "Utilities/Utils.h"
#pragma warning( push )
#pragma warning( disable : 4005 ) // macro redefinition (no effect)
#include <cufft.h>
#include <cuda_runtime.h>
#pragma warning( pop )
#include <complex>
The HUGE_VALF macro is defined in both included files.
I tried to #undef HUGE_VALF before including any of the above headers, but I still got the same warnings.
Since I have to use both Intel and Microsoft maths libraries, how can I prevent this warning from being generated?
If you really have to use two libraries with overlapping identifier names (poor you, I feel with you) then the only clean way is to use them from separated .c files.
I.e. make one .c file which includes the header for one lib and a second .c file which includes the header of the other lib.
Problems with overlapping macro definitions should be solved this way.
If you additionally have overlapping linker identifiers (function names, global variable names...), then it will be necessary to link the two code files separatly to the corresponding libs.
The real trouble starts if you then have to use functionalities from both libs in one function written by you. That will require to first wrap the two functionalities in uniquely named functions in the corresponding code files, which then can be unambigously called from another code file to use both.
Do not try to solve your problem with #undef, that is just a way to risk (or, according to murphy law, guarantee) that the wrong definition of overlapping macro names will be used unexpectedly.
In short, if you think that #undef could help you, then your problem is larger than you are aware of.
This might seem cynical, please understand that I only try to let you benefit from some serious scorch-mark experiences I made. Debugging in the presence of uncleanly overlapping symbols will get you singed. As I have mentioned in my profile, I learned to supersticiously consider #undef to be unlucky.
But, to also answer the actual question you wrote, to get rid of the "redefinition" symptom (not the problem, mind) you need to do the #undef BETWEEN the two includes, not before. That way the first include defines the problematic macro. Then it gets undefined. Then the second include defines it again, without seeing it already being defined.
My header file contains, among other things:
#define PAUSE system("pause");
typedef unsigned char uint8;
static const double PI = 3.14159265358979323846;
static const double oneDegInRads = PI / 180;
I've been including this header file into many .cpp files all over the place without a single problem. As I want to clean up my code I was fixing warnings, mostly minor stuff like "cast double to float, possible loss of data", or "unsigned to signed mismatch" warnings. So I turned on the "Treat compiler warnings as errors" in the settings, so by using that I can have a strict assessment of how bad my code is and fix it accordingly. With it turned on, my solution won't build, and shows the error:
Code Description File
C2220 "Warning treated as error - no 'object' file generated myDefinitions.h
I know why this is happening, as I turned that specific setting on. I have tried suppressing and disabling this warning with:
#pragma warning (disable : 2220)
And I've tried also following the "One CPP for each header rule", making a "myDefinitions.cpp" and including only the header and nothing else, but the error message still comes up.
So my questions are:
1: Can I have a header file without a .cpp one (without ignoring the warnings)?
2: If not, how do I make my .cpp, as I've already tried but failed?
3: What better solution can you suggest to have one page where all your important definitions that you use very frequently are? I need to make it possible to include them anywhere you want.
Visual Studio is trying to compile your myDefinitions.h header file to an object file.
It should not do that! Only .cpp source files should be translated to object files.
I guess you probably renamed a .cpp file to myDefinitions.h at some point, and Visual Studio didn't understand you wanted to change its file "type".
Try to delete your myDefinitions.h file, and then create a new myDefinitions.h file, choosing the correct file type from the new file dialog. You can then put the old content into that new header.
OK, thank you to both Ton Plooij and Johan Boule. The reason this was happening was that in my header file there were implicit type conversions such as:
C4305: 'initializing': truncation from 'double' to 'float'
In the Error tab it only said:
"Warning treated as error - no 'object' file generated
Which led me believe that it was LOOKING FOR a CPP file, which is strange because header files aren't made into object files. What I didn't know is that I could find the "Warning" that triggered the "Error" message by clicking on the "Warnings" tab. And it showed exactly which "Warnings" made the "Error" show up.
Thanks again for your help.
The C2220 error occurs because there are warnings. Since there are warnings, no object or executable will be generated. You can't disable this C2220, it's what you enabled with the /WX option. So, either fix all warnings or disable the /WX (Treat all warnings as errors) option.
Using C++ Native solution in Visual Studio 2010.
#pragma warning (push) is used in the beginning of the cpp file, after all the includes. After that there are couple of disabled warning by #pragma warning(disable : XXXX).
What are possible consequences of omitting #pragma warning(pop) at the end of the file?
Thanks
If you have any other source files that #include that cpp file, then the warning state when compiling the outer file will be messed up -- it could fail to give warnings when the warnings were warranted.
Note, however, that #includeing a cpp file is considered bad form and a code smell; there are certain, rare, situations where it might be the right thing to do (such as a build system that #includes many source files into one to reduce compilation times, sort of like precompiled headers), but almost always it's the wrong thing to do, even if it manages to compile and link without errors.
If that source file is never #included anywhere else, then failing to have a #pragma warning(pop) will not have any adverse consequences, assuming the compiler doesn't complain about that mismatch in the first place.
Since this is a compiler only setting, it won't have any impact on the program itself. It may though screw up warnings for external includes.
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.
So the other day I went to compile a VC++ project I am working on and all of a sudden I get errors in almost all of my files saying:
new.h: error C2039: 'set_new_handler' : is not a member of 'std
new.h: error C2039: 'set_new_handelr' : symbol cannot be used in a using-declaration
"new.h" and 'set_new_handler' are not being used in any of my files, so I have no idea how or why these errors are suddenly appearing since they relate to a windows/VS library file.
Would anyone know what I can do to clear this error and compile my code again?
UPDATE After examining the files being included upon compilation, some files are including and some are . The problem is that is being included in afxwin.h and is being included in a third-party library. I honestly have no idea what to do with this problem...no other developers that have played with this code are running into this problem, may it be a settings problem? I am not using precompiled headers.
If I were to hazard a guess, I would say that <new.h> declares set_new_handler in the global namespace and <new> declares it within the std namespace. Some code is including <new.h> and expecting it to act as if it had included <new>. I would suspect either some 3rd party library/header or a precompiled header as suggested by Evan.
You can narrow down the culprit using either /showIncludes or pre-processing a source code file (using /E) and examining the output. I usually use the latter and look at the #line directives in the output file to figure out the include chain.
Good luck.