Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Anbei mal eine sehr grobe Übersicht bezüglich meinem Projekt.
Du kannst Dir nach dem Ordnen von Chemistry ja auch einmal Gedanken zu den anderen Klassen machen. Zum Beispiel bei Transport: „Funktion zum Manipulieren von Strings“. So etwas würde ich eher in einer String-Hilfsklasse erwarten. Auch bin ich nicht ganz sicher, ob die Ableitungshierarchie, die Du aufgebaut hast, sinnvoll ist. Es gibt ein Designprinzip, welches Aggegration vor Generalisierung stellt. Das heißt, ob eine Thermodynamic-Klasse wirklich ein Transport ist und ein Chemistry ein Thermodynamic ist, musst Du Dir klar machen. Eine hat-Beziehung klänge für mich sprachlich irgendwie sinnvoller.
Wenn ich die Klasse Chemistry in ChemistryReader, ChemistryData und ChemistryCalculation aufteile, werden dann alle Header und Source Dateien in einen Ordner "Chemistry" gepackt oder wird für jede Klasse ein eigener Ordner mit Header und Source erstellt?
Ich kenn die Größe Deines Gesamtprojekts nicht, aber ich hätte bei der mir bekannten Anzahl alle Klassen in einen Ordner gepackt. Erstellt Du wirklich eigene Libraries für MixtureFraction oder Chemistry? (Wenn Du Dich auch noch mit Sichten/Views beschäftigen willst, wäre das jetzt die Definution des „Development View“.)
Soweit ich mich entsinnen kann, werden zusammengehörige Klassen/Source-/Headerdateien in den gleichen Ordner gespeichert.
Hm, nein, das macht niemand. Stell Dir vor ein System hat 5000 Klassen und man würde jede in einen eigenen Ordner legen. Da findet man ja nichts wieder. Es gäbe auch keinen sinnvollen Grund, das so zu tun. Du solltest nicht mehrere Klassen in eine Datei legen, weil zum einen die Übersicht dann leidet, aber auch Abhängigkeiten schlechter auflösbar sind. Aber auch hier gibt es Situationen, wo das Zusammenlegen von zwei Klassen in eine Datei auch sinnvoll sein kann. Gruß Dee
|
Shor-ty
(Themenstarter)
Anmeldungsdatum: 10. September 2010
Beiträge: 719
Wohnort: Bad Wörishofen
|
Dee schrieb:
Soweit ich mich entsinnen kann, werden zusammengehörige Klassen/Source-/Headerdateien in den gleichen Ordner gespeichert.
Hm, nein, das macht niemand. Stell Dir vor ein System hat 5000 Klassen und man würde jede in einen eigenen Ordner legen. Da findet man ja nichts wieder. Es gäbe auch keinen sinnvollen Grund, das so zu tun. Du solltest nicht mehrere Klassen in eine Datei legen, weil zum einen die Übersicht dann leidet, aber auch Abhängigkeiten schlechter auflösbar sind. Aber auch hier gibt es Situationen, wo das Zusammenlegen von zwei Klassen in eine Datei auch sinnvoll sein kann.
Ich meinte damit nicht die Zusammenlegung mehrerer Klassen in eine Datei sondern dass Klassen, welche starke Verknüpfungen aufzeigen (bspw. ChemistryReader, ChemistryCalculation, ChemistryData) in einen Ordner kopiert werden:
| chemistry/
├── chemistryCalc.cpp
├── chemistryCalc.hpp
├── chemistryData.cpp
├── chemistryData.hpp
├── chemistryReader.cpp
└── chemistryReader.hpp
|
Wie du schon erwähnst, wäre die Zusammenlegung mehrerer Klassen sehr unübersichtlich.
Du kannst Dir nach dem Ordnen von Chemistry ja auch einmal Gedanken zu den anderen Klassen machen. Zum Beispiel bei Transport: „Funktion zum Manipulieren von Strings“. So etwas würde ich eher in einer String-Hilfsklasse erwarten.
Das werde ich definitiv tun. Ich dachte mir zu Beginn sowieso, dass ich eine String-Klasse eröffne, die alle Manipulationen meiner Strings beinhaltet. Diese Klasse würde ich dann an die Klassen Chemistry, Transport und Thermodynamic vererben (wobei ich mir jetzt nicht sicher bin, ob die Vererbung - Klassenhierarchisch - das Richtige ist; siehe nächsten Abschnitt). Auch bin ich nicht ganz sicher, ob die Ableitungshierarchie, die Du aufgebaut hast, sinnvoll ist. Es gibt ein Designprinzip, welches Aggegration vor Generalisierung stellt. Das heißt, ob eine Thermodynamic-Klasse wirklich ein Transport ist und ein Chemistry ein Thermodynamic ist, musst Du Dir klar machen. Eine hat-Beziehung klänge für mich sprachlich irgendwie sinnvoller.
Deine Aussage macht Sinn. Alle Klassen (Chemistry, Thermodynamic und Transport) sind separate Klassen, wobei eben alle untereinander Daten austauschen müssen, bzw. für die Berechnungsmethoden der Chemistry Klasse benötige ich thermodynamische und transporttypische Daten, die von den entsprechenden Klassen kommen. Werde mir deshalb mal deine hat-Beziehung näher anschauen.
Ich kenn die Größe Deines Gesamtprojekts nicht, aber ich hätte bei der mir bekannten Anzahl alle Klassen in einen Ordner gepackt. Erstellt Du wirklich eigene Libraries für MixtureFraction oder Chemistry? (Wenn Du Dich auch noch mit Sichten/Views beschäftigen willst, wäre das jetzt die Definution des „Development View“.)
Bislang erstelle ich keine eigenen Libraries für die einzelnen Klassen. Eine Frage noch zum Abschluss. In meinem Porjekt habe ich neue Definitionen für Vektoren und Matrizen etc. definiert:
| typedef std::vector<double> scalarField;
typedef std::vector<std::vector<double> > matrix;
typedef std::vector<std::string> stringField;
typedef std::vector<std::vector<std::string> > stringMatrix;
typedef double scalar;
|
Damit will ich mir Schreibarbeit sparen und die Übersicht etwas bewahren. Sollte ich das dann für alle Typen betreiben, bspw. verwende ich andere wie folgt (std:☺:
| std::string tmp = "Foo";
std::size_t found;
|
|
Shor-ty
(Themenstarter)
Anmeldungsdatum: 10. September 2010
Beiträge: 719
Wohnort: Bad Wörishofen
|
Dee schrieb: Du kannst Dir nach dem Ordnen von Chemistry ja auch einmal Gedanken zu den anderen Klassen machen. Zum Beispiel bei Transport: „Funktion zum Manipulieren von Strings“. So etwas würde ich eher in einer String-Hilfsklasse erwarten. Auch bin ich nicht ganz sicher, ob die Ableitungshierarchie, die Du aufgebaut hast, sinnvoll ist. Es gibt ein Designprinzip, welches Aggegration vor Generalisierung stellt. Das heißt, ob eine Thermodynamic-Klasse wirklich ein Transport ist und ein Chemistry ein Thermodynamic ist, musst Du Dir klar machen. Eine hat-Beziehung klänge für mich sprachlich irgendwie sinnvoller.
Danke Dee für die Hinweise. Ich habe die Struktur meines Projektes abgeändert und hoffe das ich die Anregungen von euch Korrekt übernommen und auch verstanden habe.
Kritik ist definitiv erwünscht. Der Aufbau scheint aber jetzt verständlicher zu sein.
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Diese Klasse würde ich dann an die Klassen Chemistry, Transport und Thermodynamic vererben.
Na hoffentlich jetzt nicht mehr. 😀 In Kurzform: Keine der drei Klassen ist eine String-Klasse, sie nutzen sie alle nur. Selbst eine Komposition (als Memberdatum) könnten schon zu viel sein, sondern sie einfach nur als benutzen (also auf dem Stack anlegen), reicht vermutlich vollkommen aus.
Ich meinte damit nicht die Zusammenlegung mehrerer Klassen in eine Datei sondern dass Klassen, welche starke Verknüpfungen aufzeigen (bspw. ChemistryReader, ChemistryCalculation, ChemistryData) in einen Ordner kopiert werden:
Dann kannst Du tun. Ich würde die Überlegung aber erst dann machen, wenn diese Klassen in dem Ordner für sich genommen eine Einheit bilden, die man losgelöst als Library nutzen kann. Eine Library bzw. einen Ordner mit nur drei Klassen wäre mir persönlich zu viel Aufwand (auch wenn es geordneter ist).
Sollte ich das dann für alle Typen betreiben, bspw. verwende ich andere wie folgt
Der Vorteil ist, dass Du eine eigene Sprache aufbaust und man so leichter versteht, um was in Deinem Code geht. Ein "double" kann alles Mögliche sein, ein "scalar" ist da schon aussagekräftiger (solange Du es nur als Skalar nutzt!). Ein weiterer Vorteil ist, dass Du so leichter die Typdefinition im ganzen Projekt ändern kannst. Ganz wichtig ist dann aber, dass Du die Außenschnittstellen (z.B. zu anderen Bibliotheken) gut kontrollierst und beobachtest, damit es nicht zum Typmischmach kommt. (Aus einem signed wird ein unsigned, aus einem long ein int etc.) Bzgl. Typdefinition wäre es sorum auch verständlicher: typedef double scalar;
typedef std::vector<scalar> scalarField; Gruß Dee
|
Shor-ty
(Themenstarter)
Anmeldungsdatum: 10. September 2010
Beiträge: 719
Wohnort: Bad Wörishofen
|
Irgendwie ist meine Datei nicht mitgekommen...
Hier nochmals der Versuch (:
Diese Klasse würde ich dann an die Klassen Chemistry, Transport und Thermodynamic vererben.
Na hoffentlich jetzt nicht mehr. 😀 In Kurzform: Keine der drei Klassen ist eine String-Klasse, sie nutzen sie alle nur. Selbst eine Komposition (als Memberdatum) könnten schon zu viel sein, sondern sie einfach nur als benutzen (also auf dem Stack anlegen), reicht vermutlich vollkommen aus.
Nein mach ich nicht. War auch nur im Übertragenen Sinne so gemeint, wobei, ja ich werde versuchen Wortkonform zu schreiben ☺
Ganz wichtig ist dann aber, dass Du die Außenschnittstellen (z.B. zu anderen Bibliotheken) gut kontrollierst und beobachtest, damit es nicht zum Typmischmach kommt. (Aus einem signed wird ein unsigned, aus einem long ein int etc.)
Das Programm ist eigenständig und berechnet Flammenflächen, welche dann tabuliert abgelegt werden. | typedef double scalar;
typedef std::vector<scalar> scalarField;
|
Da gebe ich dir vollkommen recht.
- Project.pdf (27.7 KiB)
- Download Project.pdf
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Das sieht doch prinzipiell ganz gut geordnet aus. Gruß Dee
|
Shor-ty
(Themenstarter)
Anmeldungsdatum: 10. September 2010
Beiträge: 719
Wohnort: Bad Wörishofen
|
Dann werde ich das am Weekend mal etwas umstrukturiern (:
Danke für die Hilfe. Werde da sicher noch auf meine Probleme stoßen zwecks Zugriffsrechte usw. Danke Dee und den anderen.
|
Shor-ty
(Themenstarter)
Anmeldungsdatum: 10. September 2010
Beiträge: 719
Wohnort: Bad Wörishofen
|
Hallo zusammen, ich hätte jetzt kurz eine Frage.
Bspw. das Objekt "ChemistryReader". Sollte das Objekt im Programm so erstellt werden:
| int main()
{
ChemistryReader dasObjekt;
return 0;
}
|
Oder sollte ich das eher über die Chemistry Klasse über eine Funktion erstellen:
| int main()
{
Chemistry dasObjekt;
dasObjekt.NewChemistryReaderObject();
return 0;
}
|
Bzw. irgendwie so: |
int main()
{
dasObjekt::NewChemistryReaderObject();
return 0;
}
|
Ich hätte es jetzt über eine Klassenfunktion in der Chemistry-Klasse gemacht.
|
Shor-ty
(Themenstarter)
Anmeldungsdatum: 10. September 2010
Beiträge: 719
Wohnort: Bad Wörishofen
|
Hallo zusammen, ich bin jetzt wieder zum Thema dieses Threads gestoßen und hab jetzt folgendes Problem.
Meine Klasse Chemistry enthält nun eine hat-ein-Beziehung zum ChemistryReader. Die Aufgabe des ChemistryReaders ist, auf die Datei zuzugreifen und die Daten zu extrahieren/manipulieren die man benötigt.
Das Problem besteht darin, dass ich nicht weiß wie ich die Daten von der ChemistryReader Klasse auf meine Chemistry übertrage. Mein Programm sieht bislang wie folgt aus: | Chemistry chemistry;
chemistry.chemistryReader(file_Chemistry);
chemistry.readChemistry();
|
Zu Beginn erstelle ich ein Objekt der Klasse Chemistry Danach rufe ich die Funktion chemistryReader(std::string) auf; diese erstellt ein neues Objekt der Klasse ChemistryReader und liefert den Zeiger auf diese Klasse.
| void AFC::Chemistry::chemistryReader
(
const string& fileName
)
{
pCR_ = new ChemistryReader(fileName);
}
|
| void AFC::Chemistry::readChemistry()
{
pCR_->readChemistry();
}
|
Wenn ich jetzt aber in diesem Reader Dateien vorbereitet habe, dann kann ich die nicht in das Objekt chemistry delegieren, da ich ja hier das Objekt chemistry nicht habe. Für mich gibts jetzt zwei Möglichkeiten:
| void AFC::Chemistry::chemistryReader
(
const string& fileName
)
{
pCR_ = new ChemistryReader(fileName, this);
}
|
Grüße und n schönes Weekend,
Tobi
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Sollte das Objekt im Programm so erstellt werden:
Da fehlt leider der Kontext, wo und wie genau Du ChemistryReader nutzen willst. Bei dem ersten Code-Block kann ich mir die theoretische Nutzung denken. Bei 2 und 3 gibt es aber keinen Rückgabewert, sodass ich keine Ahnung habe, wo Du das Objekt ChemistryReader gerade erstellt hast.
diese erstellt ein neues Objekt der Klasse ChemistryReader und liefert den Zeiger auf diese Klasse.
Wieso liefert sie den Zeiger, wenn Du damit außerhalb nichts machst?
Ich übergebe die Referenz/Pointer des Objekts chemistry an das zu erstellende Objekt und erstell somit eine Aggregation auf beiden Seiten
Das macht man grundsätzlich nicht (so direkt), weil Du dann eine zyklische Abhängigkeit hast. Das heißt, Du brauchst immer beide Objekte, auch wenn Du eins nutzen willst. Das ist vor allem bei Unit-Tests störend.
Ich hab die Methodik der Aggregation nicht ganz verstanden und machs ziemlich falsch
Chemistry besteht doch (laut dem letzten PDF) aus mehreren Aggegrationen, eine davon hält die Daten. Hilft das bereits weiter? Allg. Hinweis: Ich würde das ganze Konzept auch etwas anders aufziehen, aber ich finde es gut, dass Du eigene Umsetzungen überlegst und verfolgst. Früher oder später merkt man dann, dass irgendetwas nicht ganz stimmig oder umständlich ist. Was im Übrigen mir bei der Programmierung hilft ist Test Driven Development, d.h. ich überlege mir erst einen Test der Außenschnittstelle (z.B. von Chemistry) und merke dann, ob die Benutzung sich „natürlich“ anfühlt oder nicht. Falls ja, habe ich die Schnittstelle definiert und implementiere sie danach. Aber DU musst jetzt nicht mit TDD anfangen. Ist vielleicht nur ein Schlagwort für später einmal. Gruß Dee
|
Shor-ty
(Themenstarter)
Anmeldungsdatum: 10. September 2010
Beiträge: 719
Wohnort: Bad Wörishofen
|
Hallo Dee, du bist mir ne große Unterstützung (danke dafür, lerne auch ziemlich viel). Also, ich habe gestern leider nicht anders umsetzen können / keine andere Idee gehabt und jetzt sieht es wie folgt aus.
Dann erstelle ich einen Pointer auf ein neues chemistryReader objekt und speichere die Adresse im chemistry Obj. Zudem wird die Adresse vom chemistry obj. in dem erstellten chemistryReader obj. gespeichert (du meintest, dass das ja nicht wirklich gut ist, aber anders bin ich nicht zurechtgekommen).
Danach rufe ich die Funktion readChemistry() auf, die dann alles weitere macht. Die Daten werden vorbereitet und dann wird im ChemistryReader obj eine Funktion vom chemistry Objekt aufgerufen, um die Daten an dieses Objekt zu delegieren. Die Daten werden dann im Objekt chemistry weiter an ein Objekt von chemistryData delegiert. Das ist glaub umständlich, weil ich in chemistry viele Funktionen erstellt hab, die die Daten lediglich zu chemistryData delegiert.
Ich bemühe mich stets die Kritiken von euch einzubinden, immerhin sind es ja sehr gute Hinweise und Abänderungsvorschläge. Finde mein Programm auch schon übersichtlicher, bis auf die Delegation der Daten von ChemistryReader via Chemistry zu ChemistryData. Da es mein erstes großes Projekt ist, bin ich auch sehr dazu geneigt gut zu programmieren und vor allem viele Neuheiten mit einfließen zu lassen.
Ach ja, "new" hab ich gestern noch mit einem Smartpointer ersetzt, zwecks Optimierung und korrekter Zerstörung des Objekts, sobald die Gültigkeit verlassen wird. Falls Interesse darin besteht was ich jetzt gemacht hab (gut oder schlecht), der kann sich hier ein Bild davon machen: automaticFlameletCreator. Ich würde mich sehr über eine Rückmeldung freuen. Bezüglich der Delegation der Daten von ChemistryReader zu ChemistryData ist mir persönlich nichts Besseres eingefallen. Wahrscheinlich ist das sehr einfach, nur ich machs kompliziert.
Grüße Tobi
|
Shor-ty
(Themenstarter)
Anmeldungsdatum: 10. September 2010
Beiträge: 719
Wohnort: Bad Wörishofen
|
Ich glaub ich hätte eine erste extreme Vereinfachung gefunden. Da die ChemistryReader Klasse ja ein ChemistryData Obj benötigt, wäre es wohl besser das der ChemistryReader das ChemistryData obj erstellt und somit direkten Zugang zu dem obj hat. Damit spar ich mir die ganze Delegation der Daten über die Chemistry Klasse. Zuletzt sollte halt dann die Referenz oder der Pointer auf die Klasse an das Objekt der Chemistry Klasse übergeben werden, damit die auch weiß wo die Daten zu finden sind. Denke das das schonmal ne wesentliche Verbesserung zum jetzigen Code darstellt. Außerdem auch einfacher zu verstehen. Es wird vllt noch nicht die ganz gute Lösung sein aber wesentlich besser als die derzeit. Allerdings ist dann mein Beziehungsschema anders: Chemistry hat ein ChemistryData, ChemistryCalc und ein ChemistryReader ChemistryReader hat ein ChemistryData und ist ein StringManipulator
Eigentlich sollte das auch sinnvoll sein. Der ChemistryReader kann zwar ohne ChemistryData exisitieren aber die Daten können nirgends gespeichert werden.
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Dann erstelle ich einen Pointer auf ein neues chemistryReader objekt und speichere die Adresse im chemistry Obj.
Hier ein Tipp: Halte den Lebensbereich eines Objektes immer so klein wie möglich. Konkret also: Wo genau benötigst Du chemistryReader? Ist es wirklich notwendig, dass das Objekt ein Memberdatum von chemistry ist? Muss chemistryReader wirklich so lange leben?
Da die ChemistryReader Klasse ja ein ChemistryData Obj benötigt, wäre es wohl besser das der ChemistryReader das ChemistryData obj erstellt und somit direkten Zugang zu dem obj hat.
Noch nicht optimal, aber die Richtung ist richtig. ☺ Hier ist der Tipp: Prüfe die Verantwortlichkeit der Klasse. ChemistryReader soll ja die Daten aus der Datei lesen und in ChemistryData schreiben, korrekt? Wieso erstellt ChemistryReader also zusätzlich noch ein ChemistryData? Welchen Weg gäbe es denn ohne Memberdatum in ChemistryReader auszukommen? Gruß Dee PS: Diskussion macht mir im Übrigen auch Spaß. Ich hab nur manchmal etwas viel zu tun ...
|
Shor-ty
(Themenstarter)
Anmeldungsdatum: 10. September 2010
Beiträge: 719
Wohnort: Bad Wörishofen
|
Dee schrieb: Dann erstelle ich einen Pointer auf ein neues chemistryReader objekt und speichere die Adresse im chemistry Obj.
Hier ein Tipp: Halte den Lebensbereich eines Objektes immer so klein wie möglich. Konkret also: Wo genau benötigst Du chemistryReader? Ist es wirklich notwendig, dass das Objekt ein Memberdatum von chemistry ist? Muss chemistryReader wirklich so lange leben?
Jopa das is klar. Hab ich mir auch schon gedanken gemacht. Ist ja nicht nötig das Objekt chemistryReader für das ganze Projekt am Leben zu lassen. Nachdem die Daten gelesen und delegiert worden sind, kann das Objekt auch wieder gelöscht werden. Hab ich jetzt auch so gemacht. Da die ChemistryReader Klasse ja ein ChemistryData Obj benötigt, wäre es wohl besser das der ChemistryReader das ChemistryData obj erstellt und somit direkten Zugang zu dem obj hat.
Noch nicht optimal, aber die Richtung ist richtig. ☺ Hier ist der Tipp: Prüfe die Verantwortlichkeit der Klasse. ChemistryReader soll ja die Daten aus der Datei lesen und in ChemistryData schreiben, korrekt? Wieso erstellt ChemistryReader also zusätzlich noch ein ChemistryData? Welchen Weg gäbe es denn ohne Memberdatum in ChemistryReader auszukommen?
Korrekt. Die Klasse ChemistryReader soll die Daten lesen und in chemistryData reinstecken. Allerdings brauch ich doch dazu ein Objekt, oder nicht? Ich wüsste halt das ich dann noch direkt auf die Werte zugreifen kann:
| ChemistryData::name = "ichBinEinString";
|
Allerdings brauch ich doch ein Objekt um das zu machen, oder etwa nicht? Habs noch nie ohne ausprobiert. Wenn ich's ohne mache, ist das dann nich iwo im Speicher und ich hab kein Zugriff mehr drauf? Vllt. denk ich auch grad einfach in die falsche Richtung.
Gruß Dee PS: Diskussion macht mir im Übrigen auch Spaß. Ich hab nur manchmal etwas viel zu tun ...
Mir machts auch Spaß und ich lerne viel bei dem Projekt. Derzeit ist es so, dass ich ein chemistryData Objekt von chemistryReader anlege und über die move Semantik das Objekt an mein Chemistry schiebe. Dabei wird das Objekt ChemistryReader gelöscht und ich hab nur noch das Obj. Chemistry und dort den Pointer auf das Objekt ChemistryData. (Analog für Thermodynamic und Transport). Grüße Tobi 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 | c-o Reading chemistry data
Destructor ChemistryReader
c-o Reading thermodynamic data
Destructor ThermoReader
c-o Reading transport data
Destructor TransportReader
c-o All data read successfully
c-o Re-organize data structure
Destructor TransportData
Destructor ThermoData
Destructor ChemistryData
|
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Nachdem die Daten gelesen und delegiert worden sind, kann das Objekt auch wieder gelöscht werden.
Rein Interesse halber: Auf dem Stack oder auf dem Heap?
Vllt. denk ich auch grad einfach in die falsche Richtung.
Ja, etwas. ☺ Wie wäre folgender Ablauf? Du erstellt Chemistry, was ein ChemistryData als Attribut hat. Im Konstruktor erzeugt Chemistry ein ChemistryReader Chemistry ruft ChemistryReader::read und übergibt ChemistryData dabei ChemistryReader füllt ChemistryData mit Daten
Was ist der Vorteil davon? ChemistryReader tut nur das, was er soll. Und ChemistryData gehört demjenigen, dem es gehören soll (Chemistry), wird also auch von ihm erzeugt und destruiert. Gruß Dee
|