Designfrage: Parser, Speichermanagement
-
hi,
ich habe mich (mal wieder) an einem mathematischen parser versucht.
das ganze lehnt sich ein bisschen an das interpretermuster an.aber jetzt hab ich 2 fragen:
-
is das design ok, d.h. der der aufbau, wahl und struktur
der klassen? was ist mist bzw. was wuerdet ihr anders und
besser machen? -
wie soll ich die resourcen verwalten? wenn ich den parse-tree
erstelle erzeuge ich haufenweise dynamsich obekte.
zuerst hab ich auto_ptr genommen.
jetzt bin ich aber nicht mehr sicher, ob das ne gute wahl war...
(siehe auch die diskussion im c++ forum zum thema shared pointers :))
hmm. also soll ich bei den auto_ptr bleiben oder gibts ne andere
gute moeglichkeit...?waer wirklich toll, wenn sich jemand mal die muehe machen wuerde
und reinschauen koennte.
quellcode und exe (fuer die compilier-faulen):
http://www.entelechie.de.vu/projekte/Parser[2004-08-05].zip
-
-
hat niemand ideen oder verbesserungsvorschlaege?
wie siehts mit der performance aus? ich hab das ganze
mit einem parser verglichen der keine klassen benutzt.
der scheint fast doppelt so schnell zu sein...woran kann das liegen? an dem dynamischen allokieren von
objekten? der uebermaessigen verwendung von auto_ptr?
is das ganze vielleicht zu "oversized"?
-
Ich finde es ist schnell genug, das Design ist auch ok
... Momentan arbeite ich auch an einem Parser, allerdings mit einem etwas anderen Ziel... Die Geschwindigkeit spielt ja keine _so_ grosse Rolle, da ein Paar Millisekunden mehr oder weniger auch keinen Unterschied machen.mfg h4xX0r
-
hm. also ich will den parser nutzen um z.b. funktionen zu zeichen.
da laeuft er ja schon mal n paar hundertausendmal (je nachdem
wie die genauigkeit gewuenscht is) ueber die parse methode
und wertet den parsetree aus.
da denke ich schon, dass es was ausmacht wie schnell das ganze
is.bissher hab ich noch keinen "echten" praxistest gemacht, sondern
nur mit anderen parsern verglichen.
naja mal guggn was wird...