I had a post similar to this awhile ago based on a error I was getting. I was able to fix it but since then I been having trouble doing things because headers keep blocking other headers from using code. Honestly, these headers are confusing me and if anyone has any resources that will address these types of issues, that will be helpful.
What I essentially want to do is be able to have rModel.h be included inside RenderEngine.h. every time I add rModel.h to RenderEngine.h, rModel.h is no longer able to use RenderEngine.h. (rModel.h has a #include of RenderEngine.h as well).
So in a nutshell, RenderEngine and rModel need to use each others functionalities. On top of all this confusion, the Main.cpp needs to use RenderEngine.
stdafx.h
#include "targetver.h"
#define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers
// Windows Header Files:
#include <windows.h>
// C RunTime Header Files
#include <stdlib.h>
#include <malloc.h>
#include <memory.h>
#include <tchar.h>
#include "resource.h"
main.cpp
#include "stdafx.h"
#include "RenderEngine.h"
#include "rModel.h"
// Global Variables:
RenderEngine go;
rModel *g_pModel;
...code...........
rModel.h
#ifndef _MODEL_H
#define _MODEL_H
#include "stdafx.h"
#include <vector>
#include <string>
#include "rTri.h"
#include "RenderEngine.h"
........Code
RenderEngine.h
#pragma once
#include "stdafx.h"
#include "d3d10.h"
#include "d3dx10.h"
#include "dinput.h"
#include "rModel.h"
.......Code......
As I wrote in my previous answer on this question, google about Forward declaration in C++.
This may solve your problems, but, again, circular header dependencies indicate poor application design.
At least if I understand your question correctly, you have a little bit of a problem. You basically need to structure your headers so the inclusions form a directed acyclic graph (emphasis on acyclic).
What you may have to do is break your "renderengine.h" into two pieces, one of which just contains forward declarations, and the other of which contains the rest of your current contents. You'll then include that "forward declarations" header into "rmodel.h", and include "rmodel.h" into "renderengine.h".
While there are times that this is unavoidable, such a circular dependency often points to a problem with how you've organized your modules. It's entirely possible that what you currently have as renderengine.h and rmodule.h should be a single header, or perhaps multiple headers but broken along different lines.
Related
Visual Studio 2022:
I want to Include Precompiled headers in my .cpp file but I don't know if it's worth it since I'll also need to include a non-precompiled header with almost the same headers that are in the precompiled header.
Will the non-precompiled header use the precompiled headers or will it generate the code again on each compilation?
CPP:
#pragma once
#include "Precompiled.h"
#include "No-Precompiled.h" // Basic Headers: Windows.h, Psapi.h
int main()
{
// Functions that I need from "No-Precompiled.h" but I can't Precompile it since changes in it are made on regular basis
}
No-Precompiled.h:
#pragma once
#include <windows.h>
#include <Psapi.h>
#include <d3d11.h>
class Template
{
public:
//Functions that need many same Headers.
}
Precompiled.h:
#pragma once
#include <windows.h>
#include <Psapi.h>
#include <d3d11.h>
#include <limits>
#include <complex>
#include <filesystem>
#include <iostream>
#include <string>
#include <chrono>
#include <thread>
#include <tchar.h>
#include <wincred.h>
#include <complex>
#include <math.h>
Should I just Precompile the headers that the .cpp file uses (which is not much) or is there a way to allow No-Precompiled headers to use the Precompiled headers?
Using pre-compiled headers doesn't change that much. In particular, header guards continue to work. The header guard for <windows.h> is also included in the pre-compiled state. Hence, when the compiler sees <windows.h> for the second time, it's immediately skipped.
In your case, the No-Precompiled.h header turns out to be pretty trivial, as all its headers have already been included. You're just compiling the Template.
I'd wonder a bit about the particular set of precompiled headers, though. PSapi and DirectX and IOstream? I can't really imagine a big program where you have many files using all of them. Note that <iostream> is really about std::cout, which doesn't make a lot of sense for DirectX programs.
so here the problem i have 13 include files in my program (and i am willing to include more!) but the problem is that the compiler is ignoring the last include and i can say so because i switched between two of them and the error will be always for the last lien the line number 13
here are the include files
#include <iostream>
#include <fstream>
#include <cstdlib>
#include <iomanip>
#include <vector> //for dynamic tables
#include <string>
#include <conio.h>//used for the function getch
#include "checkPassword.hpp"
#include "buffervoider.hpp"
#include "checktyping.hpp"
#include "extractline.hpp"
#include "getchoic.hpp"
#include "tableidentify.hpp"
the error here will be:
|error: 'tableidentify' was not declared in this scope|
but if i switch between #include "getchoic.hpp" and #include "tableidentify.hpp"
the error would be
|error: 'getchoic' was not declared in this scope|
also all my headers have include guards
so how to solve this problem ?
If those hpp files are yours, then remove the #include in one of them that includes the other so if tableidentify.hpp has #includes getchoic or vice versa, remove one of the includes to the other
You probably baby have circular includes: one file includes another, which includes the first.
I'm assuming that some of those headers are user defined (i.e. you made them). If so, try combining all of the user-defined header include statements in another header, then including that.
I have simple project where I use tiny ttmath library for C++ (big nums).
This library consists of 13 *.h files.
I have included all these files in a stupid way:
#include "ttmath\ttmath.h"
#include "ttmath\ttmathbig.h"
#include "ttmath\ttmathdec.h"
#include "ttmath\ttmathint.h"
#include "ttmath\ttmathmisc.h"
#include "ttmath\ttmathobjects.h"
#include "ttmath\ttmathparser.h"
#include "ttmath\ttmaththreads.h"
#include "ttmath\ttmathtypes.h"
#include "ttmath\ttmathuint.h"
#include "ttmath\ttmathuint_noasm.h"
#include "ttmath\ttmathuint_x86.h"
#include "ttmath\ttmathuint_x86_64.h"
What is the right way? I expect smth like this:
#include "ttmath\*.h"
but can not find...
What is the right way? I expect smth like this:
#include "ttmath\*.h"
but can not find...
That won't work because the preprocessor is not going to expand characters to match things in the way you expect wildcards to work.
My recommendation would be to create a single custom header file of your own, and place all the #include entries in there. For example, in your .c file, you can add your own header:
#include "my_header.h"
And the contents of my_header.h would be:
#include "ttmath\ttmath.h"
#include "ttmath\ttmathbig.h"
#include "ttmath\ttmathdec.h"
#include "ttmath\ttmathint.h"
#include "ttmath\ttmathmisc.h"
#include "ttmath\ttmathobjects.h"
#include "ttmath\ttmathparser.h"
#include "ttmath\ttmaththreads.h"
#include "ttmath\ttmathtypes.h"
#include "ttmath\ttmathuint.h"
#include "ttmath\ttmathuint_noasm.h"
#include "ttmath\ttmathuint_x86.h"
#include "ttmath\ttmathuint_x86_64.h"
Basically, you put everything in a single header, and include that one instead.
The preprocessor doesn't have an "include all" built into it. Neither does it accept wildcards in filenames. You'll have to manually include all of them.
A common solution is to place all the includes in a new .h file and include that one every time you need all of them.
I am finding some issue in the order the include headers are defined in the c / c++ files when i execute pclint.
Say the include order is ,
#include <sys/timerfd.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <fcntl.h>
#include <termios.h>
#include <errno.h>
#include <stdarg.h>
#include <string.h>
and when i execute the pclint it gives error in say , FILE is un declared etc.
Later i changed the order of include to
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <fcntl.h>
#include <termios.h>
#include <errno.h>
#include <stdarg.h>
#include <string.h>
#include <sys/timerfd.h>
i could see that many errors were gone . I am not able to figure out why is this behavior. I am using PC-lint for C/C++ (NT) Vers. 8.00w.
i have marked the include path as say, +libdir(D:\timesys\nitrogen6x\toolchain\include)
Thank You
Brijesh
Supposedly, the inclusion of header files does slightly matter, although it's rare to find such an occasion. Some include files use types, enums or something else that is only defined in another include file.
On Linux, for example, some functions require the inclusion of multiple headers. Some of the programs using those, fail if you include those headers in the wrong order.
Kinda like the final linking stage. You have to set the libs in the correct order, otherwise you may get unresolved dependencies.
If I find an example, i will post it here.
EDIT:
Found an example. Qt. Qt has the most absurdly complicated set of headers. If you include, for example, opengl.h before QtOpenGL.h, it gives you a compilation error, because inside the Qt headers it checks for the inclusion of opengl. For some reason, QtOpenGL.h must come first.
I was looking at the doom3 code on github and I notice something unusual. Several files have only one include for a file called idlib/precompiled.h and this file have includes for several other headers like
...
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
#include <assert.h>
#include <time.h>
#include <ctype.h>
#include <typeinfo>
#include <errno.h>
#include <math.h>
...
and to program headers
#include "../framework/BuildVersion.h"
#include "../framework/BuildDefines.h"
#include "../framework/Licensee.h"
#include "../framework/CmdSystem.h"
#include "../framework/CVarSystem.h"
I wonder if there's any good reason for that, because that's the first time I see such thing
This is called precompiled headers. The main benefit is dramatically increased compilation speed.
All the headers in precompiled.h are compiled only once per project. Without precompiled headers, each header content would be compiled multiple times: for each .cpp file it is included in.
Dependencies are best served with an include-once in the using source (pragma, guarding defines). That involves a very small overhead as you get a tree of repeated includes: including a header while including a header.
However for the standard libraries are/were sometimes not so well organized and to provide a standard base of headers this was easiest. It also reflects a kind of "module" idea, bundled headers for the basic layer.
As to local includes: it is likely to be non-object-oriented lazyiness, not expressing dependencies.