leider noch eine ähnliche Frage.
Situation: zwei Dateipaare i1.cpp, i1.h bzw. i2.cpp, i2.h

i1.h benötigt eine int Konstante aus i2.h und i2.h benötigt eine
int Konstante aus i2.h
Prototypen geht hier (im Ggs. zu Klassen) ja nicht, da dadurch die Konstante erneut deklariert würde.

#include "i1.h" in i2.h und #include "i2.h" in i1.h zu schreiben, geht
auch nicht, da dadurch eine Endlosschleife von #include-Vorgängen
entsteht. Geht selbst dann nicht, wenn man den üblichen Trick
#if !defined I1
#include "i1.h"
#define I1
#endif
anwendet.

Oder allgemeiner: gibt es ein allgemeines Rezept, das nicht nur mit
2, sondern auch 3,4 oder 10 Dateien funktioniert, die sich wechselseitig
includen müßten ??

Oder muß man dann für jedes Tupel von Dateien einen "Ober-Header"
i12.h schreiben, der dann i1.h und i2.h includet und entsprechend
i12.cpp, der nur i12.h includet, nicht aber i1.h und i2.h separat ?
Elegant ist das ja nicht gerade. Wieso ist das in C++ so kompliziert, in
keiner anderen Sprache, die ich kenne, aber auch nur das geringste Problem ?

??

Prototypen geht hier (im Ggs. zu Klassen) ja nicht, da dadurch die Konstante erneut deklariert würde.

Sicher geht das, nur ist das, was du für eine Konstantendeklaration hälst, eine Definition. Eine Deklaration sieht so aus:

extern const int foo;

Gibt es nicht in C++ eine Möglichkeit, so zu #includen, daß jeder gefragte Header einmal und nur einmal eingebunden wird, sodaß Endlosschleifen beim #includen einfach verhindert werden ? Führt der Compiler nicht Buch, welche Dateien er schon
includet hat, sodaß er #include-Schleifen bemerkt, bevor er ein- und
dassselbe File 256-mal eingebunden hat und/oder die Verschachtelungsgrenze
erreicht?

(für deine Anwendung würde es sich anbieten, alle gemeinsamen Deklarationen in einen unabhängigen Header zu packen - dann brauchst du in jeder Datei nur ein '#include "defs.h"' am Anfang)

Danke für die Antworten allseits. Mir ist noch eine Lösung eingefallen, die
zwar nicht so elegant ist, aber nach meinen Versuchen funktioniert:

Jede Datei incdatei.h, die irgendwann includet werden soll, umrahmen mit:

#if !defined INCDATEIH
#define INCDATEIH

... hier der ganze Rest der Datei incdatei.h .....

#endif

d.h. das #endif an's Dateiende schreiben. #include "incdatei.h" geht selbst
dann noch, wenn in incdatei.h wiederum #include "incdatei.h" steht, ohne
Endlosverschachtelung von #includes zu hervorrufen (da
ja INCDATEIH dann bereits definiert ist).

Grüße

Ach. Meinst du hiefür nicht oder allgemein nicht?
Ich finds eigentlich recht hilfreich.

Naja, welche Datei wolltest Du denn gerne zuerst anschaun, wenn Du für Datei1 Datei2 brauchst und für Datei2 die Datei1. Das ist ein generelles Problem, das sich auch mit Include-Guards nicht besteitigen läßt.

edit: Sagte CStoll schon

also zyklische Abhängigkeiten sind meines Erachtens kein prinzipieller Design-Fehler, im Gegenteil.
Zyklische Includes entstehen z.B. dadurch, daß Klasse A Bezeichner von Klasse
B benötigt. z.B. in der Form
void A::init(B aB, c aC) {
... B.getItem(...)
}

und Objekte vom Typ B ihrerseits Objekte vom Typ A übergeben werden und Methoden von A aufrufen.
Baut man dann jede Klasse in eine eigene Quelldatei, sind zyklische
Includes unvermeidlich.

Und genau so soll doch OO-Design der "reinen OO-Lehre" nach sein: Eine Menge
von Objekten, die vermittels gegenseitiger Methodenaufrufe miteinander kommunizieren.

Grüße.

Zyklische Includes entstehen z.B. dadurch, daß Klasse A Bezeichner von Klasse
B benötigt. z.B. in der Form
void A::init(B aB, c aC) {
... B.getItem(...)
}

und Objekte vom Typ B ihrerseits Objekte vom Typ A übergeben werden und Methoden von A aufrufen.

Dann nimmt man Referenzen als Parameter, wies sich gehört, und die Definitionsabhängigkeit ist geregelt.

Baut man dann jede Klasse in eine eigene Quelldatei, sind zyklische
Includes unvermeidlich.

Nö, es werden ja nur die Header inkludiert.

Und genau so soll doch OO-Design der "reinen OO-Lehre" nach sein: Eine Menge
von Objekten, die vermittels gegenseitiger Methodenaufrufe miteinander kommunizieren.

Das hat aber nichts mit zyklischen Includes zu tun.

Dein Beispiel zeigt, daß es möglich ist zyklische Abhängigkeiten einzubauen. Kannst Du auch eines geben, das zeigt, daß es nötig ist? Wenn zwei Dinge so intensiv gekoppelt sind, daß sie gegenseitig abhängig sind, inwiefern macht es dann überhaupt Sinn sie auf diese Weise in zwei Teile zu zerlegen?

Beispiel gerne:
Präzise Simulation elektronischer Schaltungen. Klasseneinteilung "Transistor", "Widerstand", "Kondensator","Leiterbahn" usw... jedes Bauteil X führt eine Liste
aller Bauteilen in der Umgebung und ihrer Abstände zum Bauteil X.

Transistor T1 liege örtlich dicht neben Widerstand R1.
Dann benötigt zur genauen Simulation T1 sowohl Wert als auch Temperatur
von R1 sowie den Abstand T1---R1, denn über die Luft im Zwischenraum manipuliert
die Temperatur von R1 den Arbeitspunkt von T1. Ebenso braucht R1 Daten von
T1, da sich das Widerstandsrauschen mit der Umgebunstemperatur ändert.

Dasselbse gilt für alle Paarungen Widerstand/Kondensator (Keramikkondensatoren
in HF-Schaltungen ändern ihre Kapazität mit der Umgebungswärme, also die
Frequenz eines HF-Schwingkreises), Transistor/Kondensator und Transistor/Transistor, usw.

In allen diesen Fällen braucht transistor.h Attribute von widerstand.h und
auch umgekehrt.

Grüße

PS. wenn man Bücher über OOP mit anderen Sprachen als C++ liest, dann
wird man feststellen, daß die wechselseitige Beeinflussung von Objekten
nicht nur unerwünscht, sondern sogar Design-Prinzip der OO ist. In Smalltalk
würde man niemals zwei Klassen zu einer vereinigen, nur weil die beiden
über messages eng gekoppelt sind.

Beispiel gerne:
Präzise Simulation elektronischer Schaltungen. Klasseneinteilung "Transistor", "Widerstand", "Kondensator","Leiterbahn" usw... jedes Bauteil X führt eine Liste
aller Bauteilen in der Umgebung und ihrer Abstände zum Bauteil X.

Da hast Du auch gleich schon ein super Stichwort mitgeliefert: Bauteil!
Wir bauen eine abstrakte Basisklasse Bauteil, die alle nötigen Infos zur Verfügung stellen kann. Alle konkreten Bauteile erben davon und führen eine Liste benachbarter Bauteile. Ein wunderschönes Beispiel, wie man entkoppeln kann. Insbesondere ist es nun einfach neue Bauteile hinzuzunehmen.

Den Rest, daß zyklische Abhängigkeiten erwünscht seien kommentiere ich einfach nicht. Da ist mir ehrlich gesagt meine Zeit zu schade.

aber eine abstrakte Basisklasse "Bauteil" zu konstruieren (das geht natürlich),
die alle Eigenschaften der realen Bauteile besitzt, geht nicht.
Ein Transistor braucht zum Beispiel Vierpol-Parameter, Kniespannung, PN-Übergangskapazitäten, die beim Widerstand sinnlos sind. Ein Kondensator
muß modelliert werden mit Eigenschaften wie Leckstrom, den gibt's aber bei der
Diode nicht und beim Transistor auch nicht.
Eine Basisklasse "Bauteil" hätte demnach nur einen Bruchteil aller Einflußgrößen
(etwa Name, Platzierung, Bauform,...) alles Elektrische wäre doch wieder vom
Bauteiltyp abhängig.

Michael E:

Kommt drauf an, wie genau mal simulieren will (oder muß). Für eine
Blinkerschaltung muß man keine Kondensatortemperaturen modellieren, aber
für einen HF-Schwingkreis, bei dem 1% Abweichung der Kapazitäten schon
10 MHz Frequenzabweichung bedeuten, ist sowas notwendig.

Oder denk mal an integrierte Schaltungen. Da beeinflußt jedes Bauteil
jedes andere, vor allem nantürlich die in der Umgebung, da ja dort
die Transistoren direkt in dasselbe Substrat eingelassen sind, in dem
auch die Widerstandsbahnen liegen. Da sind Wechselwirkungen unabdingbar,
vor allem wieder bei HF-Anwendungen.

Grüße

aber eine abstrakte Basisklasse "Bauteil" zu konstruieren (das geht natürlich),
die alle Eigenschaften der realen Bauteile besitzt, geht nicht.

Sowas will ja auch niemand haben, der verstanden hat wie Vererbung funktioniert. Ich will nur das nötige Interface bereitstellen. Alles andere machen natürlich weiterhin die konkreten Bauteile.

die Idee von MichaelE gefällt mir auch sehr gut. Warum können eigentlich Wechselwirkungen nur über zyklische Abhängigkeiten, aber nicht über eine Indirektion, nämlich die Schaltung, simuliert werden?

Lies doch mal ein beliebiges OOP-Buch, da steht auch drin, was von zyklischen Abhängigkeiten zu halten ist. Vielleicht mal ein paar generelle Probleme von zyklischen Abhängigkeiten: Man kann nur schwierig testen, Wiederverwendung ist praktisch unmöglich, wenn man nur einen Teil davon benutzen möchte. Zuguterletzt sind hierarchische Systeme (eben solche ohne zyklische Abhängigkeiten) deutlich leichter zu verstehen.

PS. wenn man Bücher über OOP mit anderen Sprachen als C++ liest, dann
wird man feststellen, daß die wechselseitige Beeinflussung von Objekten
nicht nur unerwünscht, sondern sogar Design-Prinzip der OO ist. In Smalltalk
würde man niemals zwei Klassen zu einer vereinigen, nur weil die beiden
über messages eng gekoppelt sind.

was hat das mit zyklischen abhängigkeiten zu tun? echte zyklische abhängigkeiten (um entität X definieren zu können, muss die definition von Y bekannt sein und umgekehrt) sind nicht erlaubt (außer ggf. für inline funktionen - dort ist aber der compiler für die auflösung zuständig). falsche abhängigkeiten entstehen in 95% der fälle nur, weil versucht wird, bereits beim definieren einer klasse funktionen inline zu definieren. die restlichen 5% entfallen auf etwas kompliziertere konstruktionen, die aber prinzipiell denselben fehler begehen. außerhalb von funktionen werden vollständige typen werden in C++ schließlich nur zur definition von variablen benötigt (nicht aber zu deren deklaration!) oder wenn eine klasse basisklasse einer anderen sein soll.

wie dem auch sei, das Ziel der OOP besteht darin, ein kleines "Universum"
aus miteinander kommunizierenden Objekten zu schaffen, und dabei sind zyklische Abhängigkeiten der Art "Objekt der Klasse A ruft Methode auf Objekt der Klasse B auf" und umgekehrt "B Methoden von A" ganz natürlich und ich sehe nicht, wieso das ein Design-Fehler sein soll. Mag sein, daß das in C++ Schwierigkeiten macht; C++ ist allerdings auch keine reine OO-Sprache; in "reinen" OO-Sprachen wie Smalltalk oder (annähernd "rein") Ruby sind solche Arten von Objektkommunikation jedenfalls problemlos.

Noch ein Beispiel: Das Prinzip Model-View-Controller besteht aus drei Klassen,
die im "Dreiecksverhältnis" kommunizieren (Controller ruft Methoden des GUI auf,
GUI liefert Rückgabewerte an Model, Model berechnet neuen Wert und gibt diesen
an Controller).

Grüße und schönes Wochenende

Noch ein Beispiel: Das Prinzip Model-View-Controller besteht aus drei Klassen,
die im "Dreiecksverhältnis" kommunizieren (Controller ruft Methoden des GUI auf,
GUI liefert Rückgabewerte an Model, Model berechnet neuen Wert und gibt diesen
an Controller).

Schau's Dir nochmal an. MVC entkoppelt Dinge. Die Dreieckskommunikation gibt's nicht. Model und GUI kennen sich nicht und haben auch nicht miteinander zu tun. Sie werden nur über den Controller zusammengehalten. Der einzige der beides kennt ist der Controller. Die Kommunikation von Model/View zu Controller läuft zumeist über ein abstraktes Interface zur Verarbeitung von Messages, sodaß Model/View die konkrete Implementierung des Controllers nicht kennen.

Ich sage ja auch nichts dagegen, daß Objekte der Klasse A Objekte Methoden von Objekten der Klasse B aufrufen und umgekehrt. Das dürfen sie gerne tun, solange wenigstens in einer Richtung durch ein Interface/Basisklasse entkoppelt wurde.

Ich sage ja auch nichts dagegen, daß Objekte der Klasse A Objekte Methoden von Objekten der Klasse B aufrufen und umgekehrt. Das dürfen sie gerne tun, solange wenigstens in einer Richtung durch ein Interface/Basisklasse entkoppelt wurde.

Wer den Sinn hier nicht gleich erkennt, dem empfehle ich das Studium des Dependency Inversion Principles. Wobei das eigentlich gerade unseren OOP-Freunden bekannt sein sollte.