Angenommen ich habe ein größeres Projekt. Dieses besteht aus vielen einzelnen Quellcodedateien. Einmal ".cpp" und einmal die dazugehörigen ".hpp" Dateien. Die Funktionen, Methoden, Templetes, Klassen, etc sind ja oft abhängig von anderen stellen, also von Definitionen die in ganz anderen Dateien liegen. Deswegen "include" ich die entsprechenden Headerdateien.
Sollte ich jedoch 2mal die gleiche Datei einbinden, so kommt es zu einem Fehler ( "multiple definition" ). Das ist mir irgendwie ja noch relativ verständlich. Also gibt es da diese schönen Tricks mit Präprozessormakros die doppeltes includen verhindern. Tolle Sache. Aber nun kommt mein Problem:
Die Headerdateien werden ja nun nur einmal eingebunden. Aber einige Dinge braucht man doch dennoch mehrmals. Aber ein weiteres Include bringt ja nichts... das heißt es kommt zu Fehlern wie:
- " forbids declaration of 'Button' with no type "
- oder ... " does not name a type "

Ist ja auch klar. Woher soll der davon auch was wissen? Also von den Funktionen, Klassen,... ich hab ihm ja "verboten" die entsprechenden Informationen nochmal zu holen.
Was versteh ich jetzt an dem Prinzip nicht? Was mach ich falsch? Oder macht man so was doch ganz anders?

Du hast mit Sicherheit ein anderes Problem:

Klasse1.h:
#include "Klasse2.h"

Klasse2.h:
#include "Klasse1.h"

Wenn jetzt die Klasse1.cpp übersetzt wird, wird natürlich Klasse1.h includiert. Nach dessen #define wird die Klasse2.h includiert. Dort wird auch das #define erledigt. Aber wenn jetzt wieder Klasse1.h includiert werden soll, passiert nichts.

Dadurch erhälst du einen Fehler in Klasse2.h das irgendwelche Typen nicht definiert sind.

Ist hoffentlich verständlich, kann man sicherlich schöner beschreiben ^^

Diese gegenseiten includes sind meistens auf schlechtes Design zurückzuführen. Oft aber auch durch Vorwärtsdeklarationen zu beheben.

Aber einige Dinge braucht man doch dennoch mehrmals.

Beispiel bitte.
Wenn du Dinge in Header-Files stehen hast die (innerhalb eines Source-Files) mehrfach gebraucht werden, dann ist DAS schon das Problem.

MfG SideWinder

Wie müsste ich diese jetzt includen?

// HEADER
class Window
{
private:
class Button *btn;
}

// <-- CPP -->
#include "Button.h"

Diese Gegenseitige Abhängigkeit ist aber extrem schlecht

@Blabbbbb: Danke, so funktioniert es. Aber warum ist sowas extrem schlecht? Und welche Alternativen hab ich den?

Design Problem. Window muss über Buttons bescheid wissen und muss die verwalten. Klar.
Aber wozu muss ein Button wissen, was Window ist oder gar einen Zeiger darauf halten?! Grob gesagt. Wenn du einen Button hast, könnte der doch auch ohne ein Window drum herum existieren. Jedoch ein Window, dass Buttons hat, muss die selber verwalten, oder was damit machen.

Alternative. Design überdenken.

Eine bessere Lösung würde mir da jetzt nicht einfallen. Wie würde man das sonst machen? Der Klasse "Window" das zeichnen der Buttons überlassen? So richtig blick ich das mit dem designen von Projekten wirklich noch nicht. Gibt es für so was vielleicht gute Anleitungen? Also wie man Projekte richtig plant bevor man losschreibt? Oder Buchempfehlungen?

Somit wenn der Button "sich zeichnen soll" muss er aber doch wissen wo er auf den Bildschirmkoordinaten liegt.

Jo, muss er wohl, aber er sollte sich das nicht (irgendwie) selbst holen, sondern bei dem Funktionsaufruf "zeichnen" das einfach als parameter übergeben bekommen, bzw schon im konstruktor.
Falls du die werte noch weiterhin brauchst kannst du es einfach intern speichern, aber eben nur diese 2 werte.

Es sind einige mehr Variablen die ich da übergeben müsste und auch einiges andere was ich so umschreiben muss. Was genau ist den an dieser gegenseitigen Abhängigkeit so fatal? Was kann mir da im schlimmsten Fall passieren? Welche Auswirkungen hat das? Was würde es ändern wenn die Button-Klasse sich das nicht holt, sondern alles per Werte übergeben bekommt (außer das es meiner Meinung nach unübersichtlicher werden würde)...

Hmm. So Generell würde ich sagen, dass dir diese Abhängigkeiten bei einem grösseren Projekt ziemlich schnell das Leben schwer machen. Per Übergabe ist auf eine gewisse Art schöner, da dir dann bewusst ist, dass du da Daten übergibst. Wenn ein Button jetzt auf ein Window zugreifen kann, dann kann der doch auch Funktionen davon aufrufen und das ist nicht "logisch". Warum sollt ein Button das Recht haben sein Window, wo er drin liegt zu bewegen oder zu resizen?!

Ich würde mal sagen, dass design immer wichtiger wird, je grösser das Projekt ist/wird. Aber du kannst es ruhig mal so machen. Früher oder später wirst du merken, was ich meine.

struct meineButtonDaten {
int positionX;
int positionY;
std::string name;
....
}
//in button
void button::Zeichnen(const &meineButtonDaten daten)
{
...
}

So gegenseitige Abhängigkeiten führen zu einem sehr starren code - spätere Änderungen sind teilweise gar nicht mehr möglich, man kann eigentlich alles gleich neu schreiben. Solche Änderungen passieren wohl sicher öfter, spätestens beim dritten mal würdest du auch von alleine draufkommen das solche Abhängigkeiten keine gute idee sind

Und das Argument mit dem starren Code akzeptiere ich jetzt mal Hab ja noch nicht so viel Erfahrung. Und irgendwann mal in diese "Falle" rein zulaufen möcht ich nun auch nicht... so kann ich den Code dafür auch gleich mal richtig umschreiben. Am besten gleich mit Vererbung, dann kann ich mir das auch mal richtig genauer zu gemüte ziehen (ich meiner jetzt nicht Button soll von Window geerbt werden, sondern eher so mehrere Schaltflächen)

Danke also erstmal für eure Hilfe!