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.
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.
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.
Simple question, but I can't seem to find an answer in any reference material.
If I have a #pragma warning() directive, does the compiler only define that for the current file? Or is it propagated through #includes in other files in my project?
This is probably a wider question, which isn't necessarily specific to #pragma, but that is the case I am particularly worried about.
If you put the directive in a header, it will affect any other file that includes that header. It will also affect any headers included after you use it. If you are worried about affecting other files with your use of this, you can use #pragma warning (push) and #pragma warning (pop) to undo any changes you only want to make locally to one file.
What is the warning level you use while compiling QT projects?
When I compiled with W4, I'm getting a lot of warnings such as:
C4127: conditional expression is constant
Should I compile at W3, or find other ways to handle warnings at W4, such as: adding a new header file and using pragma's(mentioned here C++ Coding Standards: 101 Rules, Guidelines, and Best Practices).
What are your practices?
Thanks.
I ran into the exact same problem you have a couple of years ago, that of setting the compiler to level 4 warnings to catch as many potiential problems as possible. At the time, I had a support contract with Qt and asked them why their code generated so many warnings. Their response was that they never gaurenteed that their code would compile without any warnings. Only that their code would run correctly.
After several attemps, I started surrounding the Qt header files with pragmas to disable the warnings as shown below -
#pragma warning(push,3) // drop compiler to level 3 and save current level
#include <QString>
#include <QVariant>
#include <QStack>
#include <QLabel>
#include <QtGui/QTableWidget>
#pragma warning(pop) // restore compiler warning level
By doing it this way, you only compile the Qt header files at the lower warning level. Or whatever level it takes to get rid of the warnings. You may have some individual warnings that still show up, so you could raise the warning level or disable individual warnings with
#pragma warning(disable: 4700)
Some Boost library files also have this problem.
Personally I just use the Makefiles that qmake generates by default... on the presumption that I can trust the guys at Nokia to have it generate Makefiles that do the right thing for the current build environment.
I do see that qmake will take some optional arguments regarding warnings, though:
The level of warning information can be fine-tuned to help you find problems in your project file:
-Wall
qmake will report all known warnings.
-Wnone
No warning information will be generated by qmake.
-Wparser
qmake will only generate parser warnings. This will alert you to common pitfalls and potential problems in the parsing of your project files.
-Wlogic
qmake will warn of common pitfalls and potential problems in your project file. For example, qmake will report whether a file is placed into a list of files multiple times, or if a file cannot be found.
Use CONFIG += warn_on in your .pro file.
See the documentation.
Option
warn_on
The compiler should output as many warnings as possible.
This is ignored if warn_off is specified.
warn_off
The compiler should output as few warnings as possible.
If you're fighting with Q_ASSERT in Visual studio, all that warning push/pop stuff won't work, since macros are "instantiated" in place, far behind you headers.
So I would suggest to redefine Q_ASSERT:
#ifdef NDEBUG
#undef Q_ASSERT
#define Q_ASSERT(x) __noop
#endif
Based on user2846246's answer, I found that adding the following early on in the compilation of whichever library uses Qt did the trick (in my case that library uses a precompiled header file in Visual Studio so I just added the code to that header file):
#ifndef _DEBUG
#undef Q_ASSERT
#define Q_ASSERT(x) __noop
#undef Q_ASSERT_X
#define Q_ASSERT_X(cond, where, what) __noop
#endif
Which is great as I dislike dropping the warning level of a whole library.
Is there a way for the preprocessor to detect if the code in current
translation unit uses(or is creating) precompiled headers?
---
The actual problem I'm facing right now is that I'm on a project that is
abusing PCH by precompiling virtually all header files. That means there is none of
the clear dependency management you can get from #includes and the compile times is awful.
Practically every change will trigger a full rebuild.
The application is way to big to just fix it in one go, and some of the old guys refuses
to belive that precompiling everyting is bad in any way. I will have to prove it first.
So I must do it step by step and make sure my changes does not affect
code that is compiled the old PCH way.
My plan is to do ifdef out the PCH.h and work on the non PCH version whenever I have some time to spare.
#ifdef USES_PCH
#include "PCH.h"
#elif
// include only whats needed
#endif
I would like to avoid defining USES_PCH at command line and manually keep it in
sync with /Y that, besides from not being very elegant, would be a pain. There is a lot of configurations
and modules to juggle with and a lot of files that don't follow project defaults.
If Visual C++ defined a constant to indicate whether precompiled headers were in use, it would probably be listed in Predefined Macros. And it's not documented there, so it probably doesn't exist. (If it does exist, it's probably undocumented and may change in a future version.)
This will not work, when using precompiled headers in Visual C++, you cannot even have any code before including a precompiled header. I was trying to do something similar, when I came across your question. After a little trial and error, I have found that there can be no code prior to the #include directive for the precompiled header when using the /Yu compiler option.
#ifdef USES_PCH
#include "stdafx.h"
#endif
result: fatal error C1020: unexpected #endif
As far as I know, it can't, but there are some heuristics: VC++ uses StdAfx.h, Borland uses #pragma hdrstop, etc.