Seems like I still don't fully understand includes after years sometimes...

[Darklink2000]

Hi guys,

I have two include related questions because I sometimes run into include problems and only get them solved very very diffecult and time (solving-time)-consuming.

I leaned C/C++ in school but it was only very basic stuff, nothing realy complicated.
For my job I had to switch to an other language and did C/C++ only seldom in my freetime.

I red this article about includes:
http://cplusplus.com/forum/articles/10627/

But even with the techniques there I got some problems a few month ago :/ (but thankfully more seldom since i red it^^ )

My questions are:
Do the include guards realy only compile one time for a WHOLE program? I only find yes as awnser in other forum searches.
But why are the already executed includes important to include in other files again? (Or is it only for IDEs?)


Example:
X.h

#ifndef X_H
#define X_H

#include "A.h"
#include "B.h"

class X {
   A a;
   B b;
};
#endif 

Y.h

#ifndef Y_H
#define Y_H

#include "A.h"
#include "C.h"

class Y {
   A a;
   C c;
};
#endif 

main.cpp

#include "X.h"
#include "Y.h"
#include "A.h"

int main() {
   X x;
   Y y;
   A a;

  return 0;
}

Assuming that the A, B and C header files have include guards too...
Means that the include guard of A protects the include again in Y.h and the last include in main.cpp? But why I need to include it in Y.h again for example.

And...

In the article there is a point where the author mentions that including any header files in source files is save moast time... but why?

Maybe I did not understand this article completly in case of a little language barrier but I think I got the moast things^^

Would be nice if anyone of you could help me out with this.

[helios]

But why are the already executed includes important to include in other files again? (Or is it only for IDEs?)

It's not terribly important (most of the time), it's just a matter of discipline. The fact that Y.h includes A.h may be an implementation detail of Y that main.cpp should not be concerned about. If later on Y doesn't need A.h anymore and stops including it, main.cpp may break if it doesn't include A.h.
This is specially true when working with standard headers, or with headers that you don't have control over. For example, in one compiler iostream may internally include string. If your code uses std::string but only includes iostream, it will work on that compiler, but may fail to compile on a different compiler.

[Darklink2000]

Ahh ok

because I remember that I sometimes couldn't use code completion for some classes where I thoght I had included them before. Thats why I am so confused about the fact that include with guards work only one time but some classes show not up.

Moast time it apeared if I tried to write Managers for lists of an abstract class and then sometimes the subclasses of the abstract class compiled with errors.

And in my worst experience I had such a scenario but also with circular dependencies & friend stuff in addition^^

Sadly I don't have one of the scenarios available anymore, this incude questionmark in my head just went so big that I had to aks without writing c++ code the last month (because of include depression) :D

So maybee I should force myself again, maybee I come to good example scenario again^^