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.
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.
I would like to use clan-tidy. The program should check if I do have header guards, which is why I set the flag llvm-header-guard. Unfortunately this checks if the header guards are llvm-style, which I don't want. I want to use #pragma once.
Does anyone have an idea how to tell clang-tidy to check for #pragma once instead of llvm-style header guards?
There is no such check in clang-tidy.
#pragma once is not part of the C++ standard (for good reasons) and until it becomes a part of the standard there is no reason to add it to clang-tidy.
You can write your own check but I don't think it's worth the effort.
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.
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.
Problem
In CodeGear C++Builder 2009 we are using the pre-compiled header injection to greatly reduce our compile times. We have the same header file being injected into multiple projects. When compiling some projects, the compiler kicks out the following warning:
[BCC32 Warning] Dateutils.hpp(43): W8058 Cannot create pre-compiled header: initialized data in header
In this example, the Dateutils.hpp is the file it's complaining about (CodeGear's header). I've seen this happen with other headers as well. What makes this interesting is that this only happens with some projects (same header being injected).
In the past, I've had to just find the header who ultimately included this errant file and remove it from my pre-compiled header file. Does anyone know what's going on here and the best way to fix it?
Update
I ended up performing a process of elimination approach to the header file and came up with an interesting finding that I cannot explain. Out of the 50+ headers that get included, when I removed vcl.h I no longer get the W8058 warnings. I do not understand this as I would imagine that this header file in particular is a prime candidate for pre-compiliation. Can anyone explain that?
One thing that may be related is the way default string parameters are handled by BCB 200x.
Functions declared like this give the "can't generate precompiled header" message.
void myFunc(const AnsiString ¶m="");
However, change it to this, and the precompiled header can be generated.
void myFunc(const AnsiString ¶m = AnsiString(""));
In my experience, that warning message is misleading. It seems that the compiler identifies "candidates" where a header might have initialized data, then when it determines that the file is actually ok, it goes on. If it doesn't find another candidate, it won't show the message. If it finds another candidate that turns out to be a real problem, it then shows the message about the first candidate.
This makes identifying the real culprit extremely difficult.
There are VCL header files that have this known issue: QC 23002. The marked severity on this item though is a "minor failure."
So the workaround options are limited:
Not using those header files (which, yes, does defeat the idea)
Modify the header files (not advisable -- hard to track changes, keep them current).
Either way, make sure that of the ones you come across, CodeGear has knowledge of those header files having that issue. That will certainly be the best way to address it long term -- let the vendor fix their problem. Supposedly CodeGear has DateUtils.hpp in their internal tests for this, but that was posted (for QC 2781) in July 2007. If the problem or certain header files affect you considerably, contact them about it.
I get this warning message when the code shows:
#include <vcl.h>
#pragma hdrstop
I found a simple fix by swapping these lines to:
#pragma hdrstop
#include <vcl.h>
Warning no longer appears.