[OOP] Welches Konzept?
-
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.