unwanted header file WinGDI.h - c++

I am doing some macros like
#define report_msg(type,msg_str).......my_special_##type(......)
#define report_error(msg_str) report_msg(ERROR,msg_str)
It works perfect under linux while when I compile with visual studio 2010 express, I see it gives error that
error C3861: 'my_special_0': identifier not found
The reason is that "ERROR" is interpreted as 0. And when I use "Go to defination" in MSVC, it goes to WinGDI.h
/* Region Flags */
#define ERROR 0
Question is why this WinGDI.h is included? How can I eliminated it without touching the code?

Solution 1:
Swap include orders of some headers -> tedious task
Solution 2:
Put NOGDI in preprocessor. In Visual Studio: Project Properties -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions -> add NOGDI.
Explanation:
Paul pointed me in the right direction. I don't use precompiled headers, so I don't include stdafx.h. My problem is related to Linux vs. Windows libraries.
In my case I use a library, which defines the constant 'ERROR' for log messages. For timestamps ctime.h is included, which uses Windows.h/WinGDI.h.

This is why macros are evil. I've seen cases where TRUE and FALSE are defined with different values in different headers. In any project of decent size it may become tedious to follow the chains of headers. Try
#undef ERROR
#define report_msg(type,msg_str).......my_special_##type(......)
#define report_error(msg_str) report_msg(ERROR,msg_str)
and hope that the "real" definition of ERROR is not needed after these statements.

WinGDI.h is probably included via Windows.h from your stdafx.h. To be sure where it is included from enable "Show includes" option here: Project settings->Configuration Properties->C/C++->Advanced->Show Includes->Yes and recompile your source.

Related

VS2017 Project configuration preprocessor definitions not working in C++ project?

I have a preprocessor definition called PRIVATE_CODE set in my VS2017 project properties (VS2017 version 15.9.6 on Windows 8.1):
Right-click on solution
Configuration Properties
C/C++
Preprocessor
Preprocessor Definitons (field)
However, when I look at code in any file that looks for it to be defined, the code is not in use. I can tell because in my dark themed IDE, the code is in the IFDEF section is dimmed and the code in the ELSE section is normal brightness.
To be absolutely sure, I put a bad line of code in each section to see which section triggered a compiler error:
#ifdef PRIVATE_CODE
// This should trigger a compiler error.
adadfadsf;
#else
// Instead, I get a compiler error here, indicating that the compiler
// is not paying attention to the preprocessor definitions I set.
asdfadfff;
#endf
Has anybody else had this problem and knows why this is happening?

How do I stop an IntelliSense PCH Warning?

A few of my header files have no includes, so I receive this message in Visual Studio 2010:
IntelliSense: PCH warning: cannot find a suitable header stop location. An intellisense PCH file was not generated.
If I add a single header, for instance:
#include <iostream>
It disappears. How can I stop this error from showing without adding (potentially unused) include>
When adding a .cpp file it inherits the PCH settings of the project.
More detailed explanation of the problem here
Solutions:
Add #pragma once at the start of the file.
It will cause your source file to be included only once in a single compilation, therefore the compiler will be satisfied and won't require additional #include
Setting your project to not use precompiled headers
Disable PCH usage for that one cpp file you've added, which will clear both IntelliSense and compiler warning/error.
Note! I'm including num 2, and 3 because some say it helped, but it only num 1 that did solve my case.
I suppose the problem is that you have precompiled header in your project (by default "stdafx.h") and to correctly solve the problem you should add
#include "stdafx.h"
at start of your header/source file.
Go to project's property and under C/C++ => Precompiled Headers, find the option "Precompiled header".
Change it to "Not Using Precompiled Headers".
Restart Visual Studio (close all active projects).
Nothing helped me except this

C++ Compiler Macro for Status of "Use Precompiled Headers"

It there a predefined c++ compiler macro that I can use to tell, whether a file is compiled with "Use Precompiled Headers", "Create Precompiled Headers", "Dont Use Precompiled Headers"?
See #IronMensan 's answer for the purpose of such a macro!
I don't think there is anything, though I certainly understand the desire for one. Whenever I have to build my cross-platform library on a system that dozen't support PCH, it takes forever since a lot of files are pulling in way more than they really need and it would be nice to trim that out. Unfortunately I can't because of how Visual Studio handles PCH. Namely that the inclusion of the PCH must be the first non-comment line of the file. From the way you worded your question, I suspect that you are also working with Visual Studio.
I am not sure if this will work for you but you could try something like this:
#include MY_PCH_FILE
And use
/DMY_PCH_FILE="myfile.h"
on the command line to control what the first include file is. After that you have full control over what gets included and proper header guards along with the optimization in most modern compilers to detect header guards could reduce build times. You can change the definition of the macro for individual file in the build settings of your project, in a similar manor to how you can change the PCH settings for each file.
Though I must admit that I am not sure what you are trying to do and I suspect this is really an XY problem
Visual Studio/MSC does not provide a predefined macro that carries the setting of the /Y[-cdu] compiler switch for inspection from source code.
However, there is a solution to the problem you are trying to solve, i.e. controlling whether or not the first non-comment line of a source file should be #include "<my pch.h>": MSC offers the /FI (Name Forced Include File) compiler switch.
This option has the same effect as specifying the file with double quotation marks in an #include directive on the first line of every source file specified on the command line [...]
This compiler switch can either be specified on the compiler's command line, or on a per-project basis through the IDE's GUI (Project -> Properties: C/C++ -> Advanced: Forced Include File).
With a combination of the /Y[-cdu] and /FI compiler switches you can both control the use and meet the requirements for using precompiled headers, from outside the source code.
In this case, I think you can create manualy yourself the macro.
You can define USE_PRECOMPILEDHDR and FORCED_INCLUDEHDR when you use precompilation like this
#if USE_PRECOMPILEDHDR
#ifndef FORCED_INCLUDEHDR
#include "stdafx.h"
#endif
#else
//..manualy include all your headers
#endif
But as other saying, except if you change for another compiler, you have no reason to use guards for this.
This feature is unlikely to exist. The whole point of precompiled headers is that the headers will be compiled with exactly the same compiler options as when compiling for real. If the compiler were to offer a way for your code to tell the difference, then you could make your code behave differently (at a preprocessor level) depending on whether the compiler is precompiling or actually compiling.
If you're looking to include header files based on whether or not precompiled headers are enabled, you should use an Include Guard instead.

Visual C++ Express 2010 suddenly won't accept #includes

I'm working with an API which has #defineed all their include files. I'm developing in Visual C++ 2010 Express, and it's been working fine up till now.
I was adding a new cpp-file to the project, and accidentally added a "Windows Form" instead. VC warned me that my project was not using CLR at the moment, did I really want to? I clicked no, and added the file as intended. After that, however, my project no longer compiles.
The code looks basically like this:
api_header.h:
#define DEFINED_HEADER_NAME "path/to/header/file.h"
stdhpf.h:
#include DEFINED_HEADER_NAME
As I said, worked fine for a long time. Now I get this:
error C2006: '#include' : expected a filename, found 'identifier'
fatal error C1083: Cannot open include file: '': No such file or directory
What is causing this? I found some post that said it was because of having turned on precompiled headers, but I checked Project properties > Configuration properties > C/C++ / Precompiled headers, and it's off (I mention the setting path since I'm new to VS, there might be more than one way to do it...).
Any ideas?
The problem almost certainly lies in the order in which the two statements are pre-processed, rather than having anything to do with inadvertently adding a Windows Form object.
This knowledge base article suggests:
The problem is in using a defined constant to specify an include file in the #include directive. The directive is being processed before the macro is completely expanded, resulting in the error.
The second error seems to confirm this, as it indicates the pre-processor is searching for an include file with an empty name:
fatal error C1083: Cannot open include file: '': No such file or directory
The order of your include files has changed. Perhaps Visual Studio inserted a #include "stdhpf.h" somewhere ahead of your #include "api_header.h".
Disable precompiled headers. It should helps.

QT warning level suggestion

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.