Tio wrote:
Look at main.cpp. It includes mainfrm.h. Then dialog1.h is included.
Stop there.
dialog1 is a class declared in dialog1.h. Since this class needs to
access the declaration for aaa, then dialog1.h needs to include aaa.h.
Including aaa.h in dialog1.cpp is therefore meaningless.
so how should I do this ?
But.. there is a bigger problem here.
What is puzzling is that you seem to be describing a dialog2 which has
a component bbb which has a component dialog2, which in turn would have
a bbb, etc...
I simplified my project,deleted some relationships. Now is :
//main.cpp
#include "main.h"
#include "dialog2.h"
#include "dialog1.h"
//dialog1.cpp
#include "work1.h"
#include "dialog1.h"
//dialog1.h
class dialog1{
public:
work1 w;
}
//dialog2.cpp
#include "work2.h"
#include "dialog2.h"
//dialog2.h
class dialog2{
public:
work2 w;
}
//work1.cpp
#include "work1.h"
//work2.cpp
#include "work2.h"
and still I have errors :
Compiling...
main.cpp
...dialog2.h(38) : error C2501: 'work2' : missing storage-class or type
specifiers
...dialog1.h(41) : error C2501: 'work1' : missing storage-class or type
specifiers
now there aren't two classes that both know about each other, but
problem doesn't disappear.
Any idea?
Let's simplify your example:
//dialog1.cpp
#include "work1.h"
#include "dialog1.h"
//dialog1.h
class dialog1{
public:
work1 w;
}
....dialog1.h(41) : error C2501: 'work1' : missing storage-class or type
specifiers
The #include directive tells the compiler to "paste in" the text of the
header at that point in the source file. So when the compiler gets to
it, dialog1.cpp looks like:
<contents of work1.h>
<contents of dialog1.h>
>From what you've shown, I can see that dialog1.cpp looks like
<contents of work1.h>
class dialog1{
public:
work1 w;
}
Two problems here. First, that class definition should end with a
semicolon. Second, can you see my difficulty in knowing what you might
have done wrong? I have no idea what your compiler is seeing because I
done know anything about the contents of work1.h. This is against the
guidelines in FAQ 5.8
http://www.parashift.com/c++-faq-lit...t.html#faq-5.8
which are designed to get you the best help in the quickest way.
Without knowing the contents of work1.h, it is impossible to know what
the exact problem is. All I can guess is that work1.h does not define
the symbol work1, but then the compiler has already told you that. Fix
whatever is wrong in work1.h (or post a minimal, complete example here
- see FAQ 5.8 - if you can't fix it yourself) and your problem will go
away.
You do seem to have a more fundamental problem though. A header file
should be a complete compileable entity in its own right. For every
header file you ever write, you should be able to create a source file
that contains nothing but the line
#include "my_header.h"
and that source file should compile with no errors. Let's imagine you
had a file called blank.cpp and it contained nothing but
#include "dialog1.h"
The compiler would see blank.cpp as
class dialog1{
public:
work1 w;
};
[I have added the semicolon at the end of the class definition]
On compiling blank.cpp, the compiler will clearly object because all it
can see is those four lines and it has nothing to tell it what work1
is. Your solution to that has been to add #include "work1.h" at the top
of blank.cpp [assuming whatever problem you currently have in work1.h
has been fixed], which means that each and every time you include
dialog1.h, you must remember to include work1.h first. However, by my
rules above, you aren't allowed to add anything to blank.cpp. You need
to add #include "work1.h" to dialog1.h. So now you have
// dialog1.h
#include "work1.h"
class dialog1{
public:
work1 w;
};
// blank.cpp
#include "dialog1.h"
And when compiling blank.cpp, the compiler sees
<contents of work1.h>
class dialog1{
public:
work1 w;
};
Assuming, as we are, that the contents of work1.h correctly defines
work1, that will now compile. Whenever you need to use the dialog1
class, you just include dialog1.h and it compiles. The burden of having
to remember to also include work1.h first has been removed.
Gavin Deane
