C++ Ansatz um Datei zu parsen

Hans schrieb:


Also erst mal stimme ich jibi zu: Ein Parser ist kein so gut geeignetes 
Beispiel. Denn die eigentlichen Parsing-Techniken sind da wie dort 
dieselben.

> Ein "Unterprogramm" soll eine Textdatei parsen, dabei geht es um
> Datensätze (> 500 Stück, aber unbekannte Anzahl), diese bestehen aus
> einem symbolischen Name (= String) und ein paar Zahlen.
> Mir ist nicht ganz klar, wie ich das am geschicktesten anstelle.

Du hast prinzipiell erst mal eine Entscheidung zu treffen:
willst du die Datei in einem Rutsch parsen und in späterer Folge dir das 
erkannte Stück für Stück abholen, oder willst du sukzessive Parsen, 
während du ausserhalb das Gelesene vom Parser abholst.

Der Unterschied ist wie bei den XML-Parsern. Da gibt es 2 grundsätzlich 
verschiedene Ansätze.
Das eine sind die DOM Parser, die die XML Datei in einem Rutsch in eine 
interne Baumrepräsentierung bringen, die dann ein weiterer Folge mit 
Operationen auf dem Baum abgefragt, behandelt, verändert und auch von 
dort wieder geschrieben werden können.

Oder willst du XML mit SAX parsen, bei dem du den Parser auf die Datei 
löslässt und jedesmal, wenn der wieder einen Teil erkannt hat, macht der 
Parser Callbacks in deinen Code um dir mitzuteilen, dass (und was) er 
etwas erkannt hat.


Das sind erst mal die beiden grundsätzlichen Möglichkeiten, die du hast. 
Beide haben ihre Vor- und Nachteile, die sich hauptsächlich (aus meiner 
Sicht) um den Speicherverbrauch drehen. Bei einem DOM-Parser baut nun 
mal der Parser selbst eine interne Datenstruktur auf, aus der du dir 
dann möglicherweise Ausschnitte holst, um sie dann in deiner eigenen 
Datenstruktur zu duplizieren. Ein SAX-Parser hingegen speichert selbst 
keine bzw. nur kaum Daten zwischen, sondern es obliegt dem Aufrufer 
dafür zu sorgen, dass er die Teile speichert, die er haben will. Das 
kann durchaus in der Form sein, dass du eine Klasse (bzw. ein paar 
Klassen) hast, die gemeinsam die Datenstruktur repräsentieren, die es zu 
füllen gilt.

Das wäre deine erste Entscheidung, die du treffen musst.

> Wahrscheinlich eine Klasse anlegen, die einen "Parser" representiert.
> Dem Konstruktor würd ich den Dateinamen der Textdatei mitgeben.

Kann man machen. Wird sogar sinnvoll sein.

> Ich denke, ich lege mir für einen Datensatz eine Struktur (oder interne
> Klasse) an, un sammle diese in einem std::vektor.

Das kommt drauf an, was deine Daten Repräsentieren. Sind die alle vom 
gleichen Typ?

> Dann wirds aber schwammig. Soll der Konstruktor dann das ganze Parsen
> gleich in einem Rutsch erledigen?

Finde ich keine so gute Idee.
Wenn du dem Parser einen Filenamen mitgibst, dann ok - kann man so 
machen. Aber ich würde auf jeden Fall eine Funktion vorsehen, mit der 
ich explizit dem Parser auffordern kann: Jetzt File parsen.

> Wie komm ich an die Datein ran?

Das hängt jetzt davon ab, für welches Modell du dich entschieden hast.
Baut der Parser selbst eine Datenstruktur auf oder nicht?

Im ersten Fall:
Wie ist deine Datenhierarchie? Ist das eine lineare Hierarchie oder ist 
das eine Baumstruktur? Welche Zugriffe benötigst du? Wie identifizierst 
du einen Datensatz? Hast du etwas, das als Schlüssel fungieren kann?

> Grundsätzlich wohl über einen Getter

Na ja. Das ist jetzt aber sehr plakativ vereinfacht. Ich will ein Auto 
bauen - was brauch ich? 4 Räder. No, na.

PS: du solltest dir angewöhnen, in Klassen nicht in Form von Gettern und 
Settern zu denken. Die Gefahr ist groß, dass du dann nicht 
objektorientiert arbeitest sondern "C mit Klassen" erzeugst. Letzteres 
hat mit Objektorientierheit wenig zu tun.

> aber dazu muss der Benutzer der
> Klasse erstmal wissen, wieviele Datensätze eingelesen wurden.

Muss er das?
Warum kann er nicht einen 'Iterator' haben, der beim ersten Datensatz 
beginnt und den er laufend 'erhöht' um sich einen Datensatz nach dem 
anderen zu holen. Wenn er überhaupt sequentiell auf die Daten zugreifen 
können muss - was ja noch lange nicht gesagt ist. Denn: wer sagt dass 
der Parser sich darum kümmern muss? In erster Linie ist es ja eine 
Datenstruktur, die du um Werte befragst, wo ich immer diese 
Datenstruktur dann auch ihre Ergüsse her hat. Selbstverständlich kann 
bei einem DOM Ansatz der Parser selber so eine Datenstruktur beinhalten 
- muss aber nicht. Die kann genausogut auch vom Verwender kommen.

> Denkbar wäre auch, dem Getter einen String (also den Bezeichner des
> Datensatzes) zu übergeben, aber dann müsste ich im Getter jeweils alle
> Datensätze auf diesen String vergleichen.

Wieso musst du das?
Das ist ja wohl ein Implementierungsdetail in der Datenhaltung des 
Parsers, wie der seine Daten speichert. Von aussen interessiert dich das 
herzlich wenig. Im Parser spricht auch nichts dagegen (wenn deine 
Strings eindeutig sind), dass die Datensätze als std::map gespeichert 
sind.

> Wie würdet ihr das lösen?

Erst mal, indem ich mich frage:
Komme ich damit durch, dass der Parser die Daten hält? Kann ich den 
Parser an sich, gleich als meine 'Datenhaltung' verwenden? Ist DOM für 
mich das richtige, oder ist der SAX Ansatz das richtige, weil ich den 
Parser zb von einer Klasse 'ConfigData' benutze und es da völlig 
ausreicht, wenn der Parser dieser Klasse bescheid gibt, dass er einen 
Satz von der Datei gelesen hat und ConfigData sich dann die Werte dieses 
einen Satzes holt und in seiner eigenen Datenstruktur aufhebt.

Hans schrieb:

> Stimmt, da hast du recht.
> Ich hätte bisher schon auch eine Klasse zur Datenrepresentation
> angelegt. Allerdings hätt ich diese intern im Parser verwendet, und dort
> auch einen Vektor (oder eben Map) dieser Klasse angelegt.
> Aber stimmt, macht natürlich mehr Sinn die geparsten Datensätze nach
> außen hin verfügbar zu machen. Nur stellt sich dann die frage, wem
> "gehören" die Datensätze dann? Der main()?

Demjenigen, der sie anlegt :-)

> Wenn Parser und Datensatz zwei getrennte Klassen sind, was liefert dann
> der Parser zurück? Einen Vektor?

Ich würde in dem Fall sogar soweit gehen, dass der Parser da überhaupt 
nichts 'liefert'. Der Parser kriegt einen Filenamen und eine 
Datenstruktur und sein Job ist es diese Datenstruktur zu befüllen. 
Punkt. Aus.
Egal wer dann auch immer den Parser benutzt, egal wie oft der Parser in 
einem Programm benutzt wird, derjenige der den Parser benutzen will, hat 
ein Datenstruktur-Objekt zur Verfügung zu stellen. Der Parser schreibt 
da hinein, so wie ein Promi auf das Papier schreibt, welches ihm der Fan 
unter die Nase hält. Der Fan ist für Papier und Bleistift zuständig, der 
Promi benutzt das nur.

jibi schrieb:
>>Finde ich keine so gute Idee.
>>Wenn du dem Parser einen Filenamen mitgibst, dann ok - kann man so
>>machen. Aber ich würde auf jeden Fall eine Funktion vorsehen, mit der
>>ich explizit dem Parser auffordern kann: Jetzt File parsen.
>
> Sogar sehr schlechte Idee, den du musst zum Parsen dann jedesmal ein
> Objekt erzeugen, was (mal ein bisschen großräumiger gedacht) den
> Speicher voll müllt. Rufst du das Ganze dann in einer Schleife auf, kann
> es dir sogar den Speicher dicht machen.
>
> Geb zu vielleicht ein bisschen viel Schwarzmalerei, aber wenn man es
> gleich richtig lernen will...


Im Prinzip ja. Wie schlimm das wirklich ist, hängt von den Details des 
Einsatzes ab. Ein Objekt in einer Schleife immer wieder zu erzeugen hat 
auch den Vorteil, dass du garantiert immer mit einem frischen Objekt 
anfängst. Bei Wiederverwendung von Objekten ist das immer so eine Sache.

Ich würde mich da an den fstream Klassen orientieren. Die können auch 
beides: Sowohl Dateiname im Konstruktor als auch explizite open calls.

jibi schrieb:
> Aber ich glaube viel wichtiger wäre ein theoretischer Ansatz wie man an
> ein Objektmodel kommt. Ich mach das meistens so:
>
> 1. Anwendungsfälle
>
> Ich sammle Anwendungsfälle die im Zusammenhang mit dem Programm stehen.
> In deinem Fall:
>
> Ich will eine Datei parsen.
>
> 2. Objektdiagram
>
> Ich überlege welche Objekte sich aus den Anwendungsfällen ergeben und
> überlege welche "Aufgaben" sie haben.

Tip von mir:
Die Aufgabe ohne Ansehen von Implementierungsdetails durchdenken.
Alles was dabei an Hauptwörtern auftaucht, ist sehr oft schon mal ein 
heißer Kandidat für eine Klasse.

Welche Hauptwörter kommen in der Aufgabenstellung vor:
Parser
Daten
Datensatz
...

Das sind alles schon mal heiße Kandidaten für eigene Klassen.
Der nächste Schritt ist, Zuständigkeiten zu definieren. Welche Klasse 
ist wofür zuständig, was ist ihre Aufgabe?

Dann überlegt man sich, wie die einzelnen Klassen zusammenspielen 
können, wenn sie 'Beamte' wären (keine Beleidigung beabsichtigt): Jede 
Klasse macht das und nur das, wofür sie zuständig ist. Fällt ein 
Teilbereich nicht in ihr definiertes Aufgabengebiet, dann gibt sie die 
Zuständigkeit an geeigneter Stelle ab. Ein Parser kann und will sich 
nicht um die Details kümmern, WIE die Daten gespeichert werden. Das ist 
Aufgabe der Datenklasse.

Aufgrund dieser Überlegungen kristallisiert sich dann meist recht 
schnell ein erstes Klassenschema heraus, samt zugehörigen notwendigen 
Member-Funktionen. Betrachte die Member-Funktionen als 'Befehle' an eine 
Klasse etwas zu tun. Genau da liegt der Unterschied zur traditionellen 
Methode: die Einheit von Daten und Funktionen ist viel stärker betont. 
Wenn du nur in 'Gettern' und 'Settern' denkst, dann bist du noch nicht 
in der OOP Welt angekommen.

jibi schrieb:

> Klingt so nach Resten im Objekt nach Funktionsaufrufen und unsaubere
> Initialisierung vor dem Aufruf...das ist aber immer Schlamperei und ganz
> ehrlich, wer erwartet bei einem Parser, das ich ihn jedesmal erzeugen
> muss zum Parsen, mal abgesehen von dem Overhead der massiv ist wenn es
> um Performance geht...da muss ja Hauptspeicher angefordert werden, das
> kostet doch massiv cpu-Zeit...

So schlimm ist das auch wieder nicht.
Die Compiler sind so dämlich dann auch wieder nicht.
Ob du jetzt auf einem Speicher deine eigene Init-Funktion aufrufst, oder 
ob der Compiler in einer Schleife auf immer demselben Speicherbereich 
einen Konstruktor Aufruf legt, schenkt sich nicht viel. Nur mit dem 
Unterschied, dass du einen Konstruktor/Destruktor-Aufruf nicht vergessen 
kannst.

Hans schrieb:

> Das mit dem Promi-Autogramm find ich grad gut.

Anderes Beispiel.
Aus der MFC

Dort gibt es eine View Klasse, deren Job es ist, die Darstellung 'seiner 
Daten' durchzuführen. Dazu wird vom Framework an geeigneter Stelle eine 
Paint Methode aufgerufen.
Die Paint Methode kriegt einen Device Context mit. Dieser Device Context 
steht für die Ausgabefläche. Die Paint Methode setzt also nicht selbst 
Pixel im Video-Speicher, sondern sie beauftragt den Device Context eine 
Linie zu zeichnen. Ob dieser Device Context in ein Fenster führt, ob das 
vielleicht am Drucker landet, am Plotter oder gar über Netzwerk auf 
einen ganz anderen Rechner führt, das braucht die Paint Methode nicht zu 
kümmern. Sie kann den Device Context nach seinen Eigenschaften befragen 
(wie groß er ist) und kann ganz abstrakt dem DC den Auftrag erteilen: 
zeichne Linie von-bis. Das eigentliche (physikalische) Zeichnen wird vom 
DC erledigt.
Die Paint-Methode vom View wird auch vielleicht nicht alles selbst 
zeichnen. Vielleicht malt sie selber nur Dinge wie ein Koordinatenkreuz 
hin und eine Beschriftung und beauftragt dann die Datenstruktur (wieder 
unter Angabe des DC) sich dort auszugeben. Vielleicht gibt es aber auch 
ein eigenes Darstellungsobjekt, welches dieselben Daten einmal als 
Liniengrafik und malen kann, während ein anderes Methodenobjekt 
dieselben Daten als Tortengrafik malen kann. Vielleicht ist aber auch 
Koordinatenkreus und Beschriftung selbst wieder in einer Klasse 
gekapselt, so dass der View im Grunde nur die 'Arbeitsaufträge' an 
weitere Objekte weiterreicht, sich zu zeichnen. All das interessiert 
aber zb das Framework wieder nicht. Wenn es gilt etwas zu malen, dann 
wendet sie sich mit einem DC an den View mit dem Auftrag "da rein 
malen".
Jede Klasse hat ihre Zuständigkeit. Was kann sie, welche Aufgabe hat 
sie? Und ja, das kann durchaus sein, dass es dann auch Klassen gibt, 
deren Aufgabe darin besteht, nach 'aussen hin' als Ansprechpartner zu 
fungieren und dann die Arbeitsaufträge intern zu verteilen.
So wie in einer Firma: Als Mechaniker interessiert dich nicht, wie die 
Werkzeugausgabe intern funktioniert. Der Mann an der Ausgabe ist dein 
Ansprechpartner. Brauchst du etwas, wendest du dich an ihn. Ob der dann 
den Azubi ins Lager schickt oder selber geht; nach welchem System er das 
gesuchte Werkzeug findet, ist nicht dein Bier. Dafür bist du nicht 
zuständig. Genauso wie es den Mann am Schalter nicht interessiert, wie 
du das Werkzeug dann einsetzt. Natürlich hat man sich beim 'Design' der 
Werkzeugausgabe daran orientiert, wie die Werkzeugausgabe wohl meistens 
benutzt werden wird - man will ja schliesslich auch niemandem Prügel 
zwischen die Beine werfen. Aber im Grunde hast du mit der Theke in der 
Ausgabe eine ganz klare Trennlinie zwischen den Zuständigkeiten. Und das 
ist gut so, denn es erlaubt dir jeden der beiden Bereiche zu verändern, 
ohne das dieses den anderen Bereich großartig verändert.