quote:
Your header files should in my opinion not include any other files, instead the cpp files should include what is neeed. Other people will probably have opionions about this, but that''s what I use and like. My header files never have any #include statements.

I agree in general that it''s good to avoid #includeing in headers if you can avoid it but it''s not always possible to avoid it. What if you want to inherit from a class defined in another header? Or have a member of a type defined in another header? I don''t see how you can code C++ without sometimes including a header in another header. You might be able to do it if you''re just coding in straight C I suppose.

quote:
Mattnewport, it''s possible to as I said. Suppose you have classes CBase and CDerived in base.h/cpp and derived.h/cpp, and use them from main.cpp.

base.cpp must (obviously) include base.h
derived.cpp must include base.h and derived.h (in that order).
Your main.cpp must include base.h and derived.h (in that order).

You''re right. I''ve adopted some of the design rules from ''Large Scale C++ Software Design'' and have been using them for a while now so I''d forgotten that you don''t actually have to do things the way it suggests... One of the design rules is that the .c/.cpp file of a component should include it''s own .h file as the first substantive line of code. This ensures that the .h file will compile without requiring the .cpp file it is included in to include certain other .h files before it in a particular order.

I think it''s bad design to require someone including a .h file to include all the other .h files required to get that .h to compile in some particular order. Say you change the private implementation of a class foo to use std::strings instead of character arrays and as a result have to #include <string> in order to compile the class definition (because it has a private string member replacing a private char* or char array). That''s purely an implementation change and should only require other files using the class to be recompiled. If the .h does not include all the .hs on which it depends then all the files that use the class will have to be edited to #include <string> before they #include "foo.h".

In my opinion someone wishing to use a class you have written from another file (even if that someone is usually you) should be able to do so simply by #including the header file for that class. They should not have to include some arbitrary number of other header files in a particular order to use your class. Unless you document exactly which header files need to be included (and since the compiler doesn''t automatically check your documentation it will get out of date) then the poor programmer will have to waste time figuring out which header files he needs to include and which he can do without by looking at the corresponding .cpp file. I also think that it should be possible to use the class regardless of where in the ordering of #include directives the .h file appears. I think these concerns outweigh any benefits that might be gained from not #including any .h files in other .h files.