So, thanks to this website, I found the answer to my previous problem. I'm adding a function to a class in a GNU automake project that uses a pointer to a doc object. Dependencies were included in the Makefile.am file to include doc.h and plsa.h in the respective order. However, when I compiled, I would get a doc has not been declared error. Then, I tried adding the #include statement here, which gives a previous redefinition of 'class doc' error.
I learned that I have to declare doc by using the class doc; line commented out below; however, I thought that this was only necessary if I was declaring a function that passes the object by value. Can someone explain to me why the #include is incorrect in this case?
#include "doc.h"
//class doc;
class plsa {
// ...
int infer(doc *trset, int maxiter, double noiseH);
}
Why the Redefinition errors?
Please ensure that your header files have appropriate Header Guards/Include Guards.It is most likely that you have missed adding header guards and hence that causes multiple class definitions due to the header getting included multiple times.
Why Forward Declaration is okay in this case?
When instead of including the header file you add the line:
class doc;
It Forward declares the class doc which means for compiler it is an Incomplete type. With Incomplete types, One cannot create objects of it or do anything which needs the compiler to know the layout of docor more than the fact that doc is just an type.
i.e: The compiler does not know what are its members and what its memory layout is.
But Since pointers to all objects need just the same memory allocation, You can use the forward declaration when just reffering to an Incomplete type as a pointer.
In this case the only way in which doc is being referenced is an pointer to the class doc and hence the Forward declaration will work as well.
BottomLine:
Including the header file should work for you If you have proper Inclusion Guards in-place.
And there is nothing wrong with it.
However, Forward declaring the class should also work for you because of the reasoning given above.Note that forward declarations are usually used in case where there is a Circular Dependency of classes.
Which is better Include header File or Forward Declaration?
Including the header file just copy pastes the code from the header to wherever the file was included, which basically could lead to:
Increase in compilation time
Pollution of global namespace.
Potential clash of preprocessor names.
Increase in Binary size(in some cases though not always)
Forward Declaration has its own limitations on how the Incomplete type can be used further on.
With Incomplete type you can:
Declare a member to be a pointer or a reference to the incomplete type.
Declare functions or methods which accepts/return incomplete types.
Define functions or methods which accepts/return pointers/references to the incomplete type (but without using its members).
With Incomplete type you cannot:
Use it as a base class.
Use it to declare a member.
Define functions or methods using this type.
Given the possibility(due to above limitations on Incomplete type usage) One should prefer Forward Declaration over Including Header.
You are missing include guardians. if you just include files they are just pasted you need to make sure when they are included multiple times that they other times the code isn't duplicated. so you use a construct like this.
#ifndef _XXX_
#define _XXX_
/* your header here */
#endif
Related
When I started learning C++ I learned that header files should typically be #included in other header files. Just now I had someone tell me that I should include a specific header file in my .cpp file to avoid header include creep.
Could someone tell me what exactly that is, why it is a problem and maybe point me to some documentation on when I would want to include a file in another header and when I should include one in a .cpp file?
The "creep" refers to the inclusion of one header including many others. This has some unwanted consequences:
a tendency towards every source file indirectly including every header, so that a change to any header requires everything to be recompiled;
more likelihood of circular dependencies causing heartache.
You can often avoid including one header from another by just declaring the classes you need, rather than including the header that gives the complete definition. Such an incomplete type can be used in various ways:
// Don't need this
//#include "thingy.h"
// just this
class thingy;
class whatsit {
// You can declare pointers and references
thingy * p;
thingy & r;
// You can declare static member variables (and external globals)
// They will need the header in the source file that defines them
static thingy s;
// You can declare (but not define) functions with incomplete
// parameter or return types
thingy f(thingy);
};
Some things do require the complete definition:
// Do need this
#include "thingy.h"
// Needed for inheritance
class whatsit : thingy {
// Needed for non-static member variables
thingy t;
// Needed to do many things like copying, accessing members, etc
thingy f() {return t;}
};
Could someone tell me what exactly [include creep] is
It's not a programming term, but interpreting it in an Engish-language context would imply that it's the introduction of #include statements that are not necessary.
why it is a problem
Because compiling code takes time. So compiling code that's not necessary takes unnecessary time.
and maybe point me to some documentation on when I would want to include a file in another header and when I should include one in a .cpp file?
If your header requires the definition of a type, you will need to include the header that defines that type.
#include "type.h"
struct TypeHolder
{
Type t;
// ^^^^ this value type requires the definition to know its size.
}
If your header only requires the declaration of a type, the definition is unnecessary, and so is the include.
class Type;
struct TypeHolder
{
Type * t;
// ^^^^^^ this pointer type has the already-known size of a pointer,
// so the definition is not required.
}
As an anecdote that supports the value of this practice, I was once put on a project whose codebase required ONE HOUR to fully compile. And changing a header often incurred most or all of that hour for the next compilation.
Adding forward-declarations to the headers where applicable instead of includes immediately reduced full compilation time to 16 minutes, and changing a header often didn't require a full rebuild.
Well they were probably referring to a couple of things ("include creep" is not a term I've ever heard before). If you, as an extreme rule, only include headers from headers (aside from one matching header per source file):
Compilation time increases as many headers must be compiled for all source files.
Unnecessary dependencies increase, e.g. with a dependency based build system, modifying one header may cause unnecessary recompilation of many other files, increasing compile time.
Increased possibility of namespace pollution.
Circular dependencies become an issue (two headers that need to include each other).
Other more advanced dependency-related topics (for example, this defeats the purpose of opaque pointers, which causes many design issues in certain types of applications).
As a general rule of thumb, include the bare minimum number of things from a header required to compile only the code in that header (that is, enough to allow the header to compile if it is included by itself, but no more than that). This will combat all of the above issues.
For example, if you have a source file for a class that uses std::list in the code, but the class itself has no members or function parameters that use std::list, there's no reason to #include <list> from the class's header, as nothing in the class's header uses std::list. Do it from the source file, where you actually need it, instead of in the header, where everything that uses the class also has to compile <list> unnecessarily.
Another common technique is forward declaring pointer types. This is the only real way to combat circular dependency issues, and has some of the compilation time benefits listed above as well. For example, if two classes refer to each other but only via pointers:
// A.h
class B; // forward declaration instead of #include "B.h"
class A {
B *b;
}
// B.h
class A; // forward declaration instead of #include "A.h"
class B {
A *a;
}
Then include the headers for each in the source files, where the definitions are actually needed.
Your header files should include all headers they need to compile when included alone (or first) in a source file. You may in many cases allow the header to compile by using forward declarations, but you should never rely on someone including a specific header before they include yours.
theres compie time to think of, but there's also dependancies. if A.h includes B.h and viceversa, code won't compile. You can get around this by forward referancing your class, then including the header in the cpp
A.h
class B;
class A
{
public:
void CreateNewB():
private:
B* m_b;
};
A.cpp
#include "B.h"
A::CreateNewB()
{
m_b = new B;
}
I am getting this compiler error
error: 'RawLog' does not name a type
Here is the relevant code:
//DataAudit.h
#ifndef DATAAUDIT_H
#define DATAAUDIT_H
class RawLog;
class DataAudit
{
...
private:
RawLog* _createNewRawLog(); // This is the line indicated with the error
};
#endif // DATAAUDIT_H
Usually a forward declaration resolves this kind of error. This answer indicates that a circular header inclusion may cause this. But doesn't the use of the #ifndef and #define statements prevent circular header inclusion?
Is there another reason I might see this error?
What are some avenues of approach I could use to further deduce the nature of this error?
Update: This is rather odd. I have a Globals.h file, and if I define a new enum in Globals.h, the error appears. Then if I comment out the enum, the error goes away. This leads me to think that the circular dependency has existed for a while, and adding the enum somehow re-orders the compilation units, thus exposing the dependency that wasn't there before?
The #ifndef header guard doesn't prevent circular dependencies. It just prevents multiple inclusions of the same header in a single file.
Looks like a circular dependency to me. This means you #include a header in DataAudit.h that #includes DataAudit.h either directly or indirectly.
In the end, I am not sure I understand completely why the error occurred, but this is what I did to resolve it, and some other related information. Maybe this will help others that come across this question.
For each header file in my project
For each #include "..." in the header
If there are no references to the class in the #include, remove it.
If there are only pointers to the class defined in the #include, then replace it with a class ... forward declaration.
If there is a member instance of the class defined in #include and it makes sense to use a pointer and allocate the member on the heap, then change the member to a pointer, and replace the #include with a class .... forward declaration.
Go through my Globals.h and move anything that can be moved out of it to more localized and specific header files.
Specifically, remove an enum that was defined is Globals.h, and place it in a more localized header file.
After doing all this I was able to make the error go away. Strangely enough, the enum in Globals.h seemed to be a catalyst for the error. Whenever I removed it from Globals.h, the error would go away. I don't see how this enum could cause the error, so I think it indirectly led to the error somehow. I still wasn't able to figure out exactly how or why, but it has helped me for this guideline when coding in C++:
Don't put anything in a header file unless it needs to be there. Don't
place anything in a Globals.h that can be placed in a more localized
file. Basically, do all you can to reduce the amount of code that is
included through the #include directives.
I'm using a helper class to log messages in the android ndk in an easy way. It works like that:
LOGE("ClassTag", "Message");
Since I don't want to write the tag manually every time I want to log something, I define a TAG constant for every class definition:
#define TAG "Class1Tag"
And then I can just log by doing:
LOGE(TAG, "Message");
The problem comes up when a class with the defined TAG constant includes another class which has the same TAG constant declared. Then the following compilation error pops up:
error: "TAG" redefined
How can I take rid of the redefinitions without having to use a different identifier for every #define?
It sounds like you are defining the TAG value in the header file. For this type of thing to work properly, you should only define it in the implementation file. Because the implementation file is not included in the other files, there will be no redefinition.
One implication of this is that logging statements can only occur in the implementation file.
Define them in the respective .cpp files instead of in the headers.
Or use a private, static, const std::string or array of char, which would let you use logging statements in the header while being invisible to other classes.
If you define the same identifier in several different header files, you are not likely to get the behavior you want. In a given implementation file, the value for the identifier is going to be the last one defined, not necessarily the one associated with the class. The "last one defined" will be the one in the last header file included in the implementation file, e.g.
a.h:
#define TAG "ClassA"
b.h:
#define TAG "ClassB"
a.cpp:
#include "a.h"
#include "b.h"
For this example, uses of TAG in a.cpp will have the value "ClassB".
Basically, you never want to re-define identifiers in your header files. If you define an identifier in an implementation file that is the same as one in another implementation file, that can work because it won't be visible when compiling the other implementation files. But the compiler is complaining for a reason, and you should heed what it is telling you to avoid confusion.
EDIT: I know your compiler is flagging it as an error; the upshot of what I said is don't relax your compiler complaints to accept what you have, because that will probably result in confusion.
why not use #under TAG before #define TAG "ClassTag"
I have a class called GameState in its own file and that class has a pointer to another object of type StatusView which is in its own file. In GameState.h, I have included the StatusView header but when I try to compile it, I get the error:
missing type specifier - int assumed
However, when I forward declare StatusView even after including it, I am able to compile it. I have no clue what's causing the requirement to forward declare the class.
You have a circular dependency between the headers. A includes B and B includes A, but B doesn't really include A because #pragma once was already evaluated for A. (It would be the same with a standard header guard.)
Because the inner inclusion is ignored, it's as if it were never there at all, and you need the forward declaration.
http://www.learncpp.com/cpp-tutorial/19-header-files/
It mentions the following as another solution to "forward declaration":
A header file only has to be written once, and it can be included in as many files as needed. This also helps with maintenance by minimizing the number of changes that need to be made if a function prototype ever changes (eg. by adding a new parameter).
But, cannot this also be made with "forward declaration"? Since we are defining the function int add(int x, int y) for example in "add.cpp", and using this function in "main.cpp" by typing:
int add(int x, int y);
?
Thanks.
That is certainly possible. But for a realistically-sized program, there will be a large number of functions that a large number of other files will need to declare. If you put a forward declaration in every file that needs to access another function, you have a multitude of problems:
You've just copy-pasted the same declaration into many different files. If you ever change the function signature, you have to change every place you've pasted its forward declaration.
The forward declaration itself does not naturally tell you what file the actual function is defined in. If you use a sane method of organizing your header files and your source files (for instance, every function defined in a .cpp file is declared in a .h file with the same name), then the place that the function is defined is implied by the place that it is declared.
Your code will be less readable to other programmers, who are very used to using header files for everything (for good reason), even if all you need from a header is one specific function and you could easily forward-declare it yourself.
Header files contain forward declarations - that's what they do. The issue they resolve is when you have a more complex project with multiple source code files.
You could have a library of functions, e.g. matrix.c for matrix operations. Without header files you would have to copy the forward declarations for all the matrix.c functions into all the other source files. You would also have to keep all those copies up to date with any changes to matrix.c.
If you ever change the function in matrix.c, but forget to change its declaration in another file you will not get a compile error. You will probably not get a linker error either. All you will get is a crash or other random behaviour once you run your program.
Having the declarations in a single file, typically matrix.h, that will be used everywhere else removes all these issues.
You can use forward declaration but it doesn't scale well and it's unwieldly if you're using somebody else's code or library.
In general, the header file defines the interface to the code.
Also, think what happens if the function requires some user defined type. Are you going to forward declare that too? That type may regularly change its implementation (keeping it's public interface the same) which would result in having to regularly change all the forward declarations.
The header file solution is far more maintainable (less error prone) and make it far easier to determine exactly what code is being used.
I C and C++ one essentially put all the forward and or external declarations into the header. This then provides a convenient way of including them in the various source files without having to manually include them.
In your case, if you have add defined in add.cpp, you can just provide the external declaration in main.cpp and everything is cool. The header file is there to help you when you have a large number of files that need add declared and don't want to do so for each one.
int add(int x, int y); // forward declaration using function prototype
Can you explain "forward declaration"
more further? What is the problem if
we use it in the main() function?
It's same as #include"add.h". If you know,preprocessor expands the file which you mention in #include, in the .cpp file where you write the #include directive. That means, if you write #include"add.h", you get the same thing, it is as if you doing "forward declaration".
I'm assuming that add.h has this line:
int add(int x, int y);
What are forward declarations in C++?