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.
Related
I've seen several questions discussing this topic but none of their solutions seems to apply here. I have several libraries that I don't wont to be compiled every time I build the project so I've created "b5pch.h" and b5pch.cpp" files.
//b5pch.h
#pragma once
#include <iostream>
#include <memory>
#include <utility>
#include <algorithm>
#include <functional>
#include <sstream>
#include <string>
#include <vector>
#ifdef B5_PLATFORM_WINDOWS
#include <Windows.h>
#endif
//b5pch.cpp
#include "b5pch.h"
In properties I've set precompiled header for every cpp file to be Use(/Yu) like so:
And for b5pch.cpp it's set to Create(/Yc)
after that I've added #include "b5pch.h at the start of each cpp file(I only have two not including b5pch.cpp) but when I try to build the project I get two errors saying exactly the same thing
Error C1010 unexpected end of file while looking for precompiled header. Did you forget to add '#include "b5pch.h"' to your source?
Okay I've fixed the problem. when I was including b5pch.h in my cpp files I was doing it like this:
#include ../b5pch.h since they were in different directories.
When I moved pch files in same directory and I just wrote #include b5pch.h there were no more errors. I didn't wanted them to be in same folder so I've moved them back out but in Project Properties->Additional Include Directories I've added "src" so I could just use #include b5pch.h in my cpp files even tho they were not in the same folder.
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.
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.