![]() |
Baumstruktur in Klassen statt Array's abbilden
Hallo,
habe neulich ein Prog geladen, welches DXF lesen/schreiben kann. Dieses Prg. läuft sehr schnell, stabil und kommt sogar spielend mit Killer-Datenmengen zurecht. In den Sourcen wird ein TList-Objekt und eine Masterklasse abgeleitet, von denen sich dann die nachfolgenden Klassen ableiten. Kommt ein Knoten, wird eine neue Instanz einer Knoten-Klasse abgeleitet, welche dann wieder neue Zeichen-Klassen beinhaltet, bis wieder ein Knoten kommt oder Ende ist. Soetwas würde ich normalerweise mit Array's oder Records lösen, da leichter nachvollziehbar. Jetzt zu meinen Fragen: Die Listen der Unterklassen werden mit Listen vom Typ TList verwaltet, geht soetwas nicht auch ohne rumge-Pointere ? Ist so eine Klassen-Lösung einer Array-Lösung wirklich vorzuziehen ? Der Autor hat selbst geschrieben (frei übersetzt): Kaum zu verstehen, was wann passiert, aber es funktioniert. Und zu guter Letzt, hat jemand ein simples Beispiel, an dem ich mich probieren kann ? Schließlich müssen die angelegten Datenstrukturen auch wieder ausgelesen werden, teilweise sogar selektiv. Und spätestens beim selektiven Zugriff meine ich, wären Array's bzw. Record's besser zu handeln. So, nun überzeugt mich mal vom Gegenteil. |
Re: Baumstruktur in Klassen statt Array's abbilden
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Bleib dran, es lohnt sich. |
Re: Baumstruktur in Klassen statt Array's abbilden
Hallo Marabu,
danke für die Antwort. Zitat:
Zitat:
Oder aber, noch schlimmer, pointern selbst wie wild in der Gegend herum. Die Klassen/Polymorphie-Beispiele Mensch/Student/Fahrrad/Auto sind mir geläufig und verständlich, aber wenig hilfreich. Was ist denn ein gutes Buch. Schöner wär ein Beispiel, welches nicht so überladen ist und eine reale Funktion erfüllt. |
Re: Baumstruktur in Klassen statt Array's abbilden
Zitat:
Zitat:
Zitat:
|
Re: Baumstruktur in Klassen statt Array's abbilden
Hallo Marabu,
Zitat:
Ich hab auch schon eins gehabt, welches versprach, den geneigten (unwissenden) Leser in Delphi einzuführen. Nach dem ersten Kapitel brauchte ich Aspirin/Cognac, Aspirin/Cognac immer im Wechsel um wieder klar zu werden. Danach kamen nur noch WinAPI hier, Pointer dort. Das war aus der Buchbeschreibung und der Einleitung nicht erkennbar. OK, das war ein negativ-Beispiel, derer hab ich aber noch mehr im Schrank stehen, oft auch das genaue Gegenteil. Lauter "Die tralala-Biebel", der "irgendwas-Profi", usw. Die meisten landen nur nicht auf dem Scheiterhaufen, weil sie Geld gekostet haben und über einen schönen Einband verfügen. |
Re: Baumstruktur in Klassen statt Array's abbilden
Vielleicht gefällt dir dieser Versuch einer
![]() |
Re: Baumstruktur in Klassen statt Array's abbilden
:-D Danke für den Hinweis,
doch ich frag mich allen Ernstes, ob man nicht auch ohne ^ und @ (in Delphi) programmieren kann ?
Delphi-Quellcode:
sind das nicht sogar Relikte aus der guten alten Turbo-Pascal-Zeit ?
Zeiger = ^Datentyp;
Datentyp = RECORD Inhalt : Inhaltstyp; Nachfolger : Zeiger; END; Ergibt:
Delphi-Quellcode:
funktional nicht das Gleiche ?
Zeiger = RECORD
Inhalt : Inhaltstyp; Nachfolger : Zeiger; END; Naja, sei's Drum, die Seite ist aber trotzdem einen Favoriten-Eintrag wert. Kleine Anmerkung zu den Beispielen, also ich werd ja schon von einigen Kollegen als Herr_der_Leerzeichen beschimpft, aber wenn ich so einrücken würde; NaaaJaa :-D Übrigens (Off-Topic aber wahr): Zitat:
Geklebte Tapete löst sich bei ständig wechselnden Temperaturen/Luftfeuchtigkeiten ab, die Genagelte wird nur wellig, bleibt aber hängen. :lol: |
Re: Baumstruktur in Klassen statt Array's abbilden
Zitat:
Ich denke mal dass das zweite Beispiel sich nicht mal compilieren lässt. Das Problem ist RECORD - sobald Du Klassen benutzt bist Du nah dran, aber mit RECORDs definitiv nicht. |
Re: Baumstruktur in Klassen statt Array's abbilden
Zitat:
Lies dir mal die Quellcodes durch - die stehen im Widerspruch zu deinen beiträgen in diesem Thread. Man sollte Klassen verwenden, keine Arrays und keine Records. Und da braucht man kein ^ und kein @. |
Re: Baumstruktur in Klassen statt Array's abbilden
Zitat:
Einen PSomeBloodyRecord zu benutzen nur um sich vor Assigment By Copy zu drücken muss wohl irgendwie cooler zu sein, als ästhetischer OO Code. ;) |
Re: Baumstruktur in Klassen statt Array's abbilden
Hallo bttb930,
Zitat:
a.) es läßt sich in Delphi 7 ohne Fehler kompilieren. b.) ich habe ein altes Prog von solchen Konstrukten:
Delphi-Quellcode:
auf solche umgestellt:
Zeiger = ^Datentyp;
Datentyp = RECORD Inhalt : Inhaltstyp; Nachfolger : Zeiger; END;
Delphi-Quellcode:
und es funktioniert genauso wie vorher.
Zeiger = RECORD
Inhalt : Inhaltstyp; Nachfolger : Zeiger; END; Allerdings bekomme ich keine Warnungen vom Typ: inkompatible Typen mehr. OK, war ein bischen mehr, als nur diese eine Deklaration abändern, aber auch laut Borland-Doku ist beides identisch. |
Re: Baumstruktur in Klassen statt Array's abbilden
Delphi-Quellcode:
komisch in meinen versuchen hat das nie funktioniert....
Zeiger = RECORD
Inhalt : Inhaltstyp; Nachfolger : Zeiger; END;
Delphi-Quellcode:
das wird nicht gehen weil TTest der record selbst ist das geht nur bei klassen so.....
TTest = record
Test:Integer; test1:TTest end; |
Re: Baumstruktur in Klassen statt Array's abbilden
Hallo Michael,
Du hast Recht. In meinem Eifer hatte ich übersehen, daß es in dem Beispiel ein Record war. Bei den Sourcen, die ich umgestellt hatte, waren es immer Klassen. |
Re: Baumstruktur in Klassen statt Array's abbilden
Aus Delphi-Sprachreferenz:
Zitat:
|
Re: Baumstruktur in Klassen statt Array's abbilden
kann mal jemmand ein beispiel geben zu den gezeigt text?
ich kann mir darunter nicht so richtig was vorstellen. |
Re: Baumstruktur in Klassen statt Array's abbilden
Zitat:
Zitat:
Delphi-Quellcode:
type
TMyRecord = record mr: TMyRecord; end; |
Re: Baumstruktur in Klassen statt Array's abbilden
ja das war mich auch klar, daher meine frage wie der text es meinte.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:12 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz