Header includes in implementation file is causing errors in Qt moc - c++

Imagine I have a class foo with a header and an implementation file.
I also have those for bar. However, in bar I have an instance of foo. But I don't include foo in the header of bar but in the implementation file.
Qt's moc does not include the foo header, causing errors for not knowing the existence of the class foo.
Is there a way of keeping the include in the implementation file and having the moc add those includes as well?
foo.cpp
#include "foo.h"
foo.h
#pragma once
class foo {};
bar.cpp
#include "foo.h"
#include "bar.h"
bar.h
#pragma once
#include <QtCore>
class bar : public QObject
{
Q_OBJECT
public:
foo instanceOfFoo;
};
The moc will not include foo.h.
Which in turn generates errors telling me moc_bar.cpp is unaware of a class named foo.

The short answer is: No, you can't.
The reason is that bar has a foo member. In order to generate the definition of bar, the compiler must know what a foo is. Otherwise the memory layout of bar would be impossible to determine.
So you have to #include "foo.h" in bar.h.
You could circumvent it by using a pointer to foo and a forward declaration but it sounds wrong to me.
Also:
"The principle of keeping includes out of header files [...]"
There is no issue to have #include directives in header files. You only need to include what's necessary for your class to be completely defined (e.g. You need a std::string member ? Just #include <string>).

Related

How to break circular dependency of the headers that defines nested template class?

edit: the linked one doesn't solve this particular case, since in my case there is a nested type.
Lets imagine the situation is like this:
//foo.hpp
//include guards
template <typename T>
class foo
{
class bar;
};
The code for bar is too big, so I'd like (not really me, but it doesn't matter) to another file.
So, the current situation is this:
//foo.hpp
#include <bar.hpp>
//include guards
template <typename T>
class foo
{
class bar;
};
//bar.hpp
#include <foo.hpp>
//include guards
template <typename T>
class foo::bar
{
//...
}
This is certainly circular dependency. But the thing is that compiler (clang and gcc) accepts it.
Should I fix it or there is nothing to fix? If it is an error, how should I fix it? Should I just dump everything into one file and call it a day?
In reality, that bar is an iterator, which I wouldn't want to make standalone.
There are include guards there, so I guess that is what prevents it from being included many times, but still the circular dependency makes me worried.
Well, at first, you cannot use bar without foo, for sure... But you want to get it out of foo's header. So what about this:
foo.hpp:
//include guards
// no, we won't include bar.hpp here...
template <typename T>
class foo
{
class bar;
};
// foo::bar is now predeclared
// and now we include bar:
#include "bar.hpp"
bar.hpp is not intended to be included directly, so we just leave the inclusion of foo:
//include guards
// don't need it:
//#include "foo.hpp"
template <typename T>
class foo::bar
{
//...
};
Anyone including foo will include bar, too. To denote more clearly that bar is not intended to be included directly, I recommend moving it to a different folder with some appropriate name, e. g. "private".
Unfortunately, we might lose IDE support for foo within bar.hpp. Actually, we can simply get it back by indeed including foo.hpp within bar.hpp.
But why - then we have a circular include again???
Well, yes, we have, but the circle is broken! Remember, bar.hpp is included after foo's declaration! That is the big difference here compared to normal circular inclusion. So what happens, seen from the compiler:
foo.hpp is included somewhere, foo is declared, bar.hpp is added afterwards.
foo.hpp is included again, but the include guards are defined, the circle is broken.
Seen from the IDE it is just vice versa:
* bar.hpp includes foo.hpp
* foo.hpp includes bar.hpp again, but the guards are defined already.
So we are fine... Actually, one could now even include bar.hpp and still would get foo with.

C++ Errors: " 'class' does not name a type" and "invalid use of incomplete type ‘struct ...' "

Here is a very repetitive issue, also here in StackOverflow, but I do not manage to solve my problem even trying the different answers. So, I have some classes:
main.cpp:
#include "foo.h"
#include "bar.h"
...
foo.h:
#include "bar.h"
class foo {
foo();
bar& bind(bar &b);
gru& bind(gru &g);
};
bar.h:
#include "foo.h"
class bar {
bar();
foo& bind(foo &f);
gru& bind(gru &g);
};
Clearly, I have a cyclic dependency. So I get the infamous error 'bar' does not name a type. In this case, I add class bar; to foo declaration and delete the #include. When I do that, I get: invalid use of incomplete type ‘struct bar'.
I tried in some different ways, also adding class foo; to bar, but I always have some kind of error. In this last case I get:
bar.cpp:48:11: error: prototype for ‘foo& bar::bind(bar::foo&)’ does not match any in class ‘bar’
bar.h:55:12: error: candidates are: gru& bar::bind(gru&)
bar.h:54:13: error: bar::foo& bar::bind(bar::foo&)
Plus, I never get any complain about gru. Which, as an additional information, was already there in this program, working perfectly along with bar and main, before I added foo.
Any helpful ideas? Thanks a lot :)
in foo.h
#pragma once //(or use a guard symbol)
class bar;
class foo
{
bar & bind(bar & b);
};
in bar.h
#pragma once //(or use a guard symbol)
class foo;
class bar
{
foo & bind(foo & f);
};
in foo.cpp
#include <foo.h>
#include <bar.h>
bar foo:bind(bar & b)
{
// here you can use bar methods
}
in bar.cpp
#include <bar.h>
#include <foo.h>
foo bar:bind(foo & f)
{
// here you can use foo methods
}
This will compile fine for me (NOTE: This is without instantiating either the foo or bar class):
FILE bar.h CONTAINS:
#ifndef BAR_H
#define BAR_H
#include "foo.h"
class foo;
class gru;
class bar {
bar();
foo& bind(foo &f);
gru& bind(gru &g);
};
#endif
FILE foo.h CONTAINS:
#ifndef FOO_H
#define FOO_H
#include "bar.h"
class bar;
class gru;
class foo {
foo();
bar& bind(bar &b);
gru& bind(gru &g);
};
#endif
MAIN .cpp FILE CONTAINS:
#include "foo.h"
#include "bar.h"
Thank you a lot guys for the answers. In many ways they were helpful.
In the end I realized that I had to reorder all the #include's in my code, because, as you may have realized, there were a lot more coding and what I put here was a simpler version (sorry for that).
So, my final solution was to include class bar; in foo.h and class foo; in bar.h. Then reorder the includes in main.cpp and the Makefile.
Thanks again ;-)
The C++ compiler is very old, and furthermore, the part that handles this example in your code is not the compiler itself, but a part of the compiler chain known as the preprocessor. If we can agree on the C++ compiler being not very smart, the preprocessor is a dull, but friendly, assistant.
A *.cpp file is is compiled and later linked with the other *.cpp files in your program. The .h files actually do not have any meaning by themselves: this separation is supposedly an advantage for programmers. The key point here is that, no matter how many *.h files you included in your *.cpp file, finally there will be just a huge, generated cpp file contaning the whole code present in your *.h files, and also the source code present in your *.cpp file itself.
A cyclic dependency could be solved by many ways, but, as you can imagine, the compiler does not even have the opportunity to handle anything before the problem is produced. Cyclic dependencies are not supported in C or C++.
More modern compilers, such as Java or C#, are able to extract the public interface of classes, and use this information when the A class is needed for the B class, and viceversa. Again, this is not possible in C++.
The only solution would be to rewrite your code. The objective is to eliminate the cyclic #include directives. Actually, if your code is as simple as you are showing here, you can easily solve it by using a forward declaration:
// foo.h
class bar;
class foo {
foo();
bar& bind(bar &b);
gru& bind(gru &g);
};
--
// bar.h
class foo;
class bar {
bar();
foo& bind(foo &f);
gru& bind(gru &g);
};
--
// main.cpp
#include "foo.h"
#include "bar.h"
// ...
int main()
{
// ...
}
A forward declaration makes it possible to let the compiler know that this class actually is going to exist, and you are declaring its presence ahead, but not giving details about its contents. That's why you can just use this forward declaration for a pointer (or reference), inside another class (the compiler would need the size of the forwarded class in order to be able to create an attribute, and that's impossible without details).
There are other concepts to work here, such as compiler guards, for example.
Hope this helps.

Error: Pointer to incomplete class type is not allowed. How do I go about this?

So I have been stuck on this problem of sharing a function from one class to another and every solution I have found so far as not solved my problem.
One instance is here(I assure you there are others), [http://software.intel.com/en-us/articles/cdiag436]
Bar.h
#ifndef __Bar_h_
#define __Bar_h_
#include "BaseApplication.h"
#include <Foo.h>
class Foo;
Foo *foo;
class Bar : BaseApplication
{
public:
Bar(void);
~Bar(void);
protected:
virtual void barCreate(void);
};
#endif
Bar.cpp
#include "Bar.h"
#include <Foo.h>
Bar::Bar(void){}
Bar::~Bar(void){}
void Bar::barCreate(void)
{
if(foo->foobar()==true) //error: pointer to incomplete class type is not allowed
{//stuff}
}
Foo.h
#ifndef __foo_h_
#define __foo_h_
class Foo
{
public:
Foo(void);
~Foo(void);
bool foobar(void);
};
#endif
Foo.cpp
#include "Foo.h"
Foo::Foo(void){}
bool Foo::foobar(void){ return true; }
If I could get some pointers or explanation of where i'm going wrong that would be great.
You are misreading the error. It is not complaining about having a pointer to an incomplete type, but about dereferencing it.
if(foo->foobar()==true)
At this point the type of foo is an incomplete type, so the compiler cannot check whether it will have a foobar member function (or member functor).
Basically for an incomplete type you can declare and define pointers or references, declare interfaces (functions that take or return the type). But other than that you cannot create objects of the type, or use the pointers/references for anything other than copying the pointer/reference.
Regarding what you are doing wrong, you need to look to your real files in more details. Either you are not including the header that defines Foo, or you have multiple Foo types (different namespaces? one defines the type, another has the forward declaration) or your include guards are wrong and even if you include the header the guard discards the contents of the header. Note that after inclusion of the header that defines Foo you don't need to (and should not) provide a forward declaration of the type, as that can easily lead to multiple declarations of Foo in different contexts. If removing the forward declaration fails to compile, figure out why and fix that.

May I #include in .hpp files?

I have a class called A, which has its .cpp and .hpp files. It depends on classes B and C. Now, I'm wondering, should I #include B.hpp and #include C.hpp in A.cpp or A.hpp? I think it would be beneficial for me to #include in the A.hpp file, because I'm creating a vector of B*'s, and I'm not sure that the compiler will know the correct size of B if I only forward declare it (so I couldn't pointer increment correctly)... By "forward declaration", I mean writing class B; and class C; in the beggining of A.hpp.
As already mentioned, you can often work-around having to #include stuff by using forward declarations, and indeed the best practice is to minimize the amount of other headers included.
But: To answer your questions headline: yes you may, and the common mechanism to avoid "circular inclusion" is the following
A.hpp:
#ifndef A_HPP_INCLUDED
#define A_HPP_INCLUDED
... // code
#endif
Now if say B.hpp includes A.hpp, and subsequently, C.hpp looks like:
#ifndef C_HPP_INCLUDED
#define C_HPP_INCLUDED
#include "A.hpp"
#include "B.hpp"
...
#endif
Then you won't get an error stating that e.g. 'class A' has already been defined.
If it's a vector of B*, you don't need to include B.hpp in the other header. A forward declaration is fine. Pointers have the same size, regardless of what they point to.
It's preferred to have includes only when necessary, and this certainly looks like it's not.
I don't know if i understand your class hierarchy, in my mind is like this:
B.hpp
class B
{
B();
};
B.cpp
B::B() {};
C.hpp
class C
{
C();
};
A.cpp
A::A() {};
A.hpp
class A
{
A();
B *b;
C *C;
};
A.cpp
#include "B.hpp"
#include "C.hpp"
A::A() :
b(NULL), c(NULL)
{
};
Is this correct? (if not, please think about provide some code ;) If your class A have pointers to class B and class C a forward declaration must be the only thing you need.
I'm not sure that the compiler will know the correct size of B if I only forward declare it
Yes, as long as you include the B.hpp and C.hpp in the A.cpp file the compiler would be able to deduce its size (the class size, the pointer size is always the same). Why? Just because in the cpp file it knows the correct size due the #include. I've found this answer that would be useful to understand what I', trying to say.
Would be fine in the hpp file instead? Maybe, if your A.hpp would not be included in other files the class B and class C does not bother and spreading into another files. So, if it is the case that would not be neccessary. But IMHO the best practice is to forward declare and #include in the cpp files when it is possible.

Stacking multiple forward declarations in one header and one namespace

I have a set of classes to implement and I plan to do it in the following way:
(1) A master header file (entity.h) that has all the forward declarations of these classes enclosed in a namespace i.e.:
namespace SomeNameSpace {
class A;
...
class E;
}
(2) Each of the classes then have separate header files (i.e. A.h, B.h) that defines the classes and declares all the constituent variables and methods.
(3) And finally, the .cpp's that define all the members and statics (i.e. A.cpp, B.cpp).
Now, I tried to put this scheme to work by doing #include "entity.h", but I am slapped with an "ambiguity" error whenever I try to use one of these classes. If I skip step (1) and simply include all the individuals header files of each class, then I don't have that problem (and that's how I've been writing code).
So anyway, is my scheme viable? Is there some way to make it work? What I really wanted is to have some sort of way to put every custom object in one namespace. I suppose I can make that work by simply putting all the class declarations into one file, but that'd make entity.h bloated.
I've searched around with keywords "forward declaration", "C++", "namespace", "one namespace", "master header", "header" and couldn't find anything that's quite relevant. Maybe what I want to do is wrong?
You cannot use "class A;" in your entity.h because that means that you are actually declaring a class but you already have done so in A.h
You can either add the whole declaration in your entity.h but not using any A.h, B.h etc.
Or, you can just use the same namespace in each *.h file :
A.h ->
namespace SomeNamespace {
class A ...
}
B.h ->
namespace SomeNamespace{
class B ...
}
A different approach would be wrapping the classes into a namespace directly from the original headers, and then including them, e.g.:
A.h:
namespace SomeNameSpace {
class A{
// Class definition
void something();
}
}
A.cpp:
#include "A.h"
namespace SomeNameSpace {
void A::something()
{
}
// And other function definitions
}
entity.h:
#include "A.h"
#include "B.h"
// And so on...
You cannot use a class in a scope where there is not a complete definition (the forward declaration is not enough). Normally you might forward declare in the header and #include in the cpp. I don't see the point in organizing the way you are trying to; The canonical wisdom is to forward declare whenever possible and #include whenever necessary.