[OOP] Welches Konzept?
-
Kennst du das Buch "Design Pattern". Dort gibts das Muster "Flyweight" zur Verwaltung grosser Mengen kleiner Objekte.
Als Motivation wird ein Dokumenteneditor mit genau den von dir geschilderten Problemen verwendet.
Wenn du das Buch noch nicht hast wäre es jetzt ein günstiger Zeitpunkt, es sich zu besorgen.
mfg JJ
-
ich find das Key system sehr intressant.
man könnte in einem dword wert alle infos speichern...
1.Byte schriftart(256 verschiedene fonts reichen doch zur auswahl oder)
2.Byte zeichen
3.Byte Farben(oder anderes)
4.Byte kann man als bitfeld missbrauchen
underlined/bold/italic etc kann man da reinquetschen
wenn ein neuer wert dazukommt, wird in nem passenen set nach nem eintrag gesucht, und im zweifelsfall hinzugefügt.
reference count muss nich unbedingt sein,aber is bestimmt auch nich schlecht(geht ja schnell in nem set nach nem dword zu suchen und da einmal zu decrementeiren/incrementieren).
-
John Doe schrieb:
Kennst du das Buch "Design Pattern". Dort gibts das Muster "Flyweight" zur Verwaltung grosser Mengen kleiner Objekte.
Als Motivation wird ein Dokumenteneditor mit genau den von dir geschilderten Problemen verwendet.
Wenn du das Buch noch nicht hast wäre es jetzt ein günstiger Zeitpunkt, es sich zu besorgen.mfg JJ
Ja das Kapitel habe ich inzwischen gelesen. Bloß ist das nicht ganz das, was ich suche. Wenn ich nur 5 Formate * 256 Zeichen habe (Das sind wenige verschiedene Zeichen, denke nur an UNICODE mit plötzlich bis zu 32K Zeichen), dann ist diese "kleinste" Menge im worst case größer als wenn ich jedes Zeichen + Format einzeln speichern würde. Oder muss man da noch ein paar Seiten weiter lesen?
-----
@Herrmann: Das ist ja im Prinzip das Konzept, dass ich in meinem Text auch anspreche. Aber ob es das erweiterbarste ist? Jede Aufgabe ist irgendwie unnötig kompliziert, da gefällt mir das Key-System schon viel besser.
Dort habe ich:
a) Weniger Code-Arbeitsaufwand
b) Überhaupt keine doppelte/total unnötig gespeicherte Formate (schön)Dafür muss ich aber auch:
a) Jedesmal nachsehen ob das Format bereits vorhanden ist wenn irgendwo eine Formatänderung abläuft O(n)
b) Benötige einen GB
c) Siehe unten (nach der Anekdote), sehr großer NachteilVor allem wenn der User Fettschrift reinhaut, sich verdrückt und sie wieder rausnimmt und sie danach wieder reinwirft habe ich für die Umstellung eines einzelnen Zeichens auf Fett 3*O(n) hinter mir. Wenn ich das Container-Konzept benütze stelle ich einfach im derzeitigen Block intern den Bold-Status auf false bzw. true und fertig.
Wobei es eine Überlegung wert ist, für ein Formatänderung einfach (was sehr schnell geht) ein neues Format anzulegen und nur beim Abspeichern nachzusehen ob nicht bereits Formate doppelt vorhanden sind.
Anekdote: Denkt bitte an große Dateien nicht an eine A4-Seite. Und überlegt auch nicht so schön: "Aha Titel, Untertitel, Text. Das sind 3 Formate da fällt O(n) nicht auf" sondern auch an "Wort unterstrichen, Hyperlink, hervorgehobene Wörter mit verschiedenen Styles, Schön formatierter Quellcode, etc.).
Was mich natürlich zu einer Sache bringt: Aha wenn sich im Quellcode nur die Farbe ändert und sonst gar nichts legt der Depp schon ein neues Format an. Da mach ich lieber einen Container mit Fett/Kursiv/Unterstrichen einen mit Vordergrundfarbe/Hintergrundfarbe und habe für eine Änderung wesentlich kleinere Container durchzulaufen.
Aber! Das ist dann auch pro Zeichen ein Key mehr! Und für jeden dieser Keys benötige ich mindestens 2 Byte (man will ja mehr als 256 verschiedene Formate anbieten) => Dateigröße plötzlich mit Faktor 1,5 belastet!
Der große Nachteil von oben: Der benötigte Speicherplatz ist auch das Hauptproblem für ein möglichst portables Daten-Format. Wenn jemand eine Datei im selben Style durchschreibt (wieder an viele Daten denken) benötige ich jedesmal Zeichen+Formatkey, beim Container bleiben im Prinzip nur noch die Zeichen übrig.
Eventuell muss man diese beiden Dinge: Key + Container verbinden...aber hätte ich sowieso getan. Was mich am Container stört ist ja der große Code-Aufwand und vor allem wirds dann schwer nach Pattern im Text zu suchen. Da muss man dann plötzlich über Container-Grenzen hinweg adressieren. Da braucht man dann wieder eine Klasse die das erledigt, etc. also wie gesagt: Mehraufwand
@otze: Ja Bit-Maskierung ist in solchen Dingen sicher nicht Fehl am Platz. Zum Key-System einfach Nachteile lesen und selbst wieder urteilen und mir Bescheid geben.
Achja: Nein eigentlich plane ich noch kein Textverarbeitungsprogramm. Aber ich habe heute überlegt an was ich denken kann während das Word in der Firma 2 Minuten zum Öffnen eines files gebraucht hat :p:rolling_eyes::(
MfG SideWinder
-
Ich bin mir nicht ganz sicher ob wir uns richtig verstehen ?!
Du hast jedes vorkommende Zeichen doch nur genau einmal als Objekt. Das mögen (maximal) 32K oder auch mehr sein. Dein Text hat aber doch "theoretisch" beliebig viele Zeichen und ist damit viel grösser als deine Menge von Zeichen-Objekten.
Das ist docg das Entscheidende, das du jedes Zeichen deines Textes verwaltest und dennoch nur eine wesentliche geringere Menge von Zeichen-Objekten dafür benötigst.
Das was du gemäss diesem Muster halt an Informationen nicht mehr an jedem einzelnen Objekt mitführst kostet dich dann zwar Rechenzeit. Dadurch kannst du jedoch "beliebig" grosse Texte auf Zeichenlevel verwalten.Ich hoffe, ich hab dein Problem richtig interpretiert
mfg JJ
-
key+container, und der container sollte beim key system unbedingt ne map<DWORD,buchstabe> damit haste schonmal O(log(n)).
-
@John Doe: Jede mögliche Formatkombi * Buchstaben macht einen Speicherplatz aus der nicht auf die Platte passt...
@otze: Sehe ich auch fast so...
MfG SideWinder
-
BTW: Ich bin mir schon gar nicht mehr so sicher mit den Flags als Bits. Eventuell nur als Bit abspeichern damit die Datei schön klein bleibt. Aber im Format selbst verschlinge ich mit den vielen Bit-Operationen durch nur unnötig Zeit und wieder Aufwand.
Denn die Farbe zu bestimmten wenn die in den Bits 9-16 steht ist weitaus schwieriger als die Farbe als int32 zu haben (Abgesehen davon, dass man dann mehr Farben zur Auswahl hat *g*).
MfG SideWinder
-
Wenn du das File entweder komprimiert im RAM hast, oder sequentiel von der HDD liest, hast du doch nochmal keine Probleme wegen dem Speicher oder?
Und on the fly lesen / schreiben ist doch kein Problem - 3 Seiten als Buffer nach vorne, 3 nach hinten.
Zum eigentlichen Problem:
Aber mit den 4 Byte die Idee find ich nicht schlecht, nur mit Font beschreiben hast du da ein leichtes Problem, ausser du machst eine Font Table in dem File.Wegen der Performance mit den Bitset's wuerd ich mir nichts denken, hoer dir die Leute hier im Forum an.
-
SnorreDev schrieb:
Wegen der Performance mit den Bitset's wuerd ich mir nichts denken, hoer dir die Leute hier im Forum an.
Bisher hat sich aber nur einer dazu geäußert
MfG SideWinder
-
hmm... spontan faellt mir da eine HTML-Loesung ein
Also eine Art Auszeichnungssprache.Erstelle "unsichtbare" Zeichen, z. B. eines fuer FETTER_TEXT_ANFANG, eines fuer FETTER_TEXT_ENDE, usw. Und fuege die dann im normalen Text ein.
Wenn du dann z. B. den Text
La le lu, nur der Mann im Mond schaut zuhast, und du willst z. B. "Mann" in Fett schreiben, dann fuege vor mann ein FETTER_TEXT_ANFANG Zeichen ein und nachher ein FETTER_TEXT_ENDE. Also aehnlich wie man das bei HTML mit Tags macht.
Denkbar waere auch, dass du, anstatt fuer jede Layout-Aenderung ein eigenes FELD einzufuegen ein generelles "Layout-Zeichen" einfuegst, und dort (z. B. als Bitfeld) alle Aenderungen speicherst: ein "Bold"-Flag, ein "Italic"-Flag usw.
-
Warum stellst du den Text nicht einfach als Baumartige Hierachie da? Du nimmst dann einfach eine Basis Klasse für Dokument-Objekte, mit Funktionen um eben einen normalen Unicode Text zu erhalten, direkt auf ein Canvas zu malen (View) und eben Controller eigenschaften um zB. Links klickbar zu machen und eben die Representation (Model).
Dann würdest du
<p>foo <a href="x">bar</a> bam</p>als
text: <"foo"; link : "x", "bar"; "bam">darstellen.
-
Das mit der HTML-Lösung läuft nicht. Eventuell gibts ja für meine Probleme Lösungen, vorteilhaft wäre nämlich zB, dass immer nur jene Angaben gespeichert werden müssen, die auch wirklich von Belang sind. Aber wie so oft gibt es ein aber:
1. Ich rendere natürlich nur den Teil des Textes der auch wirklich sichtbar ist, muss aber jetzt plötzlich vor jedem Rendern die gesamte Datei durchlaufen. Was wenn der User zu Beginn sofort auf Fett-Schrift stellt und so durchschreibt. Damit ich weiß, dass die Buchstaben 1254-1555 die gerade am Bildschirm sind fett anzuzeigen sind, muss ich die gesamte Datei parsen - und das bei jeder WM_PAINT-Nachricht!
2. Der erzeugte Code wird unübersichtlich, Leertags müssen wieder rausgefiltert werden, etc. Man kennt das ja aus WYSIWYG-Editoren und deren HTML-Code.
Parser die das Ganze übersichtlicher machen (wie zB die derzeit angezeigten Container einmalig durchlaufen, nachsehen ob Nachbarn gleich sind und sie zu einem Container zusammenfügen) müssen wieder auf das gesamte Dokument angewendet werden und können nicht auf Teilbereiche angewendet werden.
Das Hauptproblem lässt sich so spezifizieren: Es dauert lang um herauszufinden welches Format das Zeichen an Position X hat da es keinen direkten Verweis auf alle Formate hat sondern solange im Text zurückgegangen werden muss bis alle Formate die auf sie wirken gefunden wurden (und das heißt immer bis zu Beginn des Textes). Gibts dafür eine Lösung?
@kingruedi: MCV bringt imho in diesem Fall nicht sehr viel. Da ein Zeichen im Prinzip ein View repärsentiert und kein Modell vorhanden ist.
MfG SideWinder
-
@SideWinder
MVC ist ja auch nicht die Grundaussage meines Beitrags, sondern nur eine Idee, wie du die Objekte auch mit Interaktion versehen kannst (ist schon besser wenn Hyperlinks sich dann direkt im default Browser öffnen ;)).Was ich eigentlich sagen wollte, dass du eben so was wie HTML machst, nur eben auf Objekt Ebene.
-
Das HTML und dem Baum nicht ordentlich funktioniert habe ich ja auch groß und lange erklärt
Sonst finde ich keine Infos mehr - oder habe ich etwas zwischen den Zeilen überlesen?
MfG SideWinder
-
Das Rich Text Format (RTF) arbeitet doch auch ähnlich HTML und funktioniert gut und schnell.
-
Das HTML und dem Baum nicht ordentlich funktioniert habe ich ja auch groß und lange erklärt
Du sollst ja kein HTML direkt nehmen. Es geht nur darum, dass du ein ähnliches System implementierst aber eben mit Objekten. Dann kannst du auch leicht eine Lösung für dein 1. Problem implementieren, in dem du einfach nach den Zeilen;Spalten queriest, was mittels Objekten nicht so langsam ist.