Wie würdet ihr einen Editor schreiben? Jede Zeile als ein Objekt?
-
dann brauchst du auch z.B. eine dynamische Liste für die vielen Anfänge und Enden einer Einfärbung, sowie der dazu passenden Farbe oder Farbindexnummer.
Das gilt für den wörterbasierten Ansatz aber genauso.
Hast du 5 Anfänge und Enden, wobei 4 davon nur für ein einzelnes Zeichen verwendet werden. Nämlich 0, '0', 0 und 'N'.
Der 5. Bereich wäre für das if.Aber immer noch besser als die 28 Wörter (wenn ich richtig gezählt habe), die bei dieser Zeile zusammenkommen.
Denk dir eine Range einfach als Wort, in dem auch Leerzeichen vorkommen dürfen.Antoras schrieb:
Von was für einem Speichermedium wurden die Daten gelesen? Eine normale Festplatte packt keine 500MB pro Sekunde.
Ich habe vorher davor gesorgt, dass die Datei im Filecache ist, daher dürfte das Medium egal sein (es ist eine Durchschnitts-SSD).
-
knivil schrieb:
Ich will schon nen Editor bauen, bei dem ich einzelne Wörter einfärben kann.
Was, wenn du Zeichenketten suchen moechtest und gefundene Farbig hervorheben moechtest? Ueber mehrere Woerter, oder auch innerhalb. Jedes Wort ein Objekt halte ich fuer schlecht.
Dann würden die Farbwerte der entsprechenden Wörter verändert werden.
Das ist sogar einfacher als das Nachschauen bei solchen Ranges, ob nicht irgendein Range schon mit dem gefunden Suchmuster überlappt.
-
Athar schrieb:
dann brauchst du auch z.B. eine dynamische Liste für die vielen Anfänge und Enden einer Einfärbung, sowie der dazu passenden Farbe oder Farbindexnummer.
Das gilt für den wörterbasierten Ansatz aber genauso.
Hast du 5 Anfänge und Enden, wobei 4 davon nur für ein einzelnes Zeichen verwendet werden. Nämlich 0, '0', 0 und 'N'.
Der 5. Bereich wäre für das if.Aber immer noch besser als die 28 Wörter (wenn ich richtig gezählt habe), die bei dieser Zeile zusammenkommen.
Denk dir eine Range einfach als Wort, in dem auch Leerzeichen vorkommen dürfen.Ich habe 31 gezählt.
Bei 1 Byte für den Farbwert, daß erlaubt 256 verschiedene Farben, das reicht völlig, würden also 31 Byte zusätzlich belegt werden.In deinem Fall wären es auf einem 64 Bit Rechner, wenn du Pointer nimmst 5*2*8 Bytes = 80 Bytes, bzw. nur 4*2*4 = 40 Bytes wenn du ein 32 Bit großes Integer nimmst und das als Arrayindexnummer verwendest.
Bei meinem Fall verliere ich dagegen den Speicherplatz bei den vielen Adresswerten für nextitem und previtem für die Wortliste.Beim erstmaligen Parsen dürfte sich das ein oder andere nicht viel tun.
Bei Veränderungen des Codes, z.B. wenn du am Anfang ein neues Wort einfügst, müßtest du die Bereiche aller deiner nachfolgenden Ranges ändern.
Ich dagegen müßte nur 2 Adresswerte von nextitem und previtem bei 2 Wortobjekten ändern und das neue Wort dazwischen einfügen.Performancemäßig haben beide Vor- und Nachteile.
-
Objekteditor schrieb:
Dann würden die Farbwerte der entsprechenden Wörter verändert werden. Das ist sogar einfacher als das Nachschauen bei solchen Ranges, ob nicht irgendein Range schon mit dem gefunden Suchmuster überlappt.
Nö, denn der zu hervorherbende Text kann mitten in einem Wort anfangen und dort auch wieder aufhören.
Und wie schon gesagt - Wörter und Ranges sind das gleiche, nur dass du beim Wortansatz auch dann eine neue Range anfängst, wenn das gar nicht nötig wäre (eben an Wortgrenzen, an denen sich die Formatierung nicht ändert).
-
Objekteditor schrieb:
Ich habe 31 gezählt.
Bei 1 Byte für den Farbwert, daß erlaubt 256 verschiedene Farben, das reicht völlig, würden also 31 Byte zusätzlich belegt werden.In deinem Fall wären es auf einem 64 Bit Rechner, wenn du Pointer nimmst 5*2*8 Bytes = 80 Bytes, bzw. nur 4*2*4 = 40 Bytes wenn du ein 32 Bit großes Integer nimmst und das als Arrayindexnummer verwendest.
Bei meinem Fall verliere ich dagegen den Speicherplatz bei den vielen Adresswerten für nextitem und previtem für die Wortliste.Ich vergaß völlig.
Wenn du mehrere Ranges hast, dann verlierst du da natürlich auch Speicherplatz für die Adressen, falls du das in einer dynamischen Liste abspeicherst.
-
Athar schrieb:
Objekteditor schrieb:
Dann würden die Farbwerte der entsprechenden Wörter verändert werden. Das ist sogar einfacher als das Nachschauen bei solchen Ranges, ob nicht irgendein Range schon mit dem gefunden Suchmuster überlappt.
Nö, denn der zu hervorherbende Text kann mitten in einem Wort anfangen und dort
auch wieder aufhören.Ok, dann müßte ich dafür ein neues Wortobjekt dazwischen einfügen und das alte in zwei neue Wörter aufspalten, sowie den Textstring entsprechend umkopieren.
Und wie schon gesagt - Wörter und Ranges sind das gleiche, nur dass du beim Wortansatz auch dann eine neue Range anfängst, wenn das gar nicht nötig wäre (eben an Wortgrenzen, an denen sich die Formatierung nicht ändert).
Naja, deine Ranges sind alle indirekt, sie sind kein Teil des Textstrings, z.b. einer Zeile.
Das ist bei mir anders, bei mir gehört die Farbe zu den Wörtern als Eigenschaft.
Und die einzelnen Wörter bilden dann den Textstring bzw, die Zeile.
-
Ich werfe mal noch zwei Begriffe in den Raum:
Fliegengewicht und Kompositum.
Die beiden Muster scheinen mir für einen Editor nützlich zu sein.
-
Objekteditor schrieb:
Ich vergaß völlig.
Wenn du mehrere Ranges hast, dann verlierst du da natürlich auch Speicherplatz für die Adressen, falls du das in einer dynamischen Liste abspeicherst.das hast du auch bei deinem Konzept. Oder willst du die Wortgrenzen jedesmal neu ermitteln? Auch halte ich dann das löschen/einfügen von Textabschnitten für ziemlich kritisch. Die Anzahl der Objekte tut sein übriges. Im schlimmsten Fall hast du so viele Objekte wie Zeichen
Ranges sind im Regelfall genau gleich zu deinem Konzept. Nur mit dem Vorteil, dass du beliebige Ranges auch über mehrere Wörter und Zeilen hinweg definieren kannst. Ganze Datei markieren: Eine Range anlegen. Bei deinem Konzept Millionen von Objekten durchlaufen und Status setzen
-
zwutz schrieb:
Objekteditor schrieb:
Ich vergaß völlig.
Wenn du mehrere Ranges hast, dann verlierst du da natürlich auch Speicherplatz für die Adressen, falls du das in einer dynamischen Liste abspeicherst.das hast du auch bei deinem Konzept.
Hab ich ja oben geschrieben.
Ganze Datei markieren: Eine Range anlegen. Bei deinem Konzept Millionen von Objekten durchlaufen und Status setzen
Ok, dieses Argument hat mich überzeugt, ich werde Ranges nutzen.
-
Objekteditor schrieb:
Ganze Datei markieren: Eine Range anlegen. Bei deinem Konzept Millionen von Objekten durchlaufen und Status setzen
Ok, dieses Argument hat mich überzeugt, ich werde Ranges nutzen.
Noch etwas.
Allerdings müssen die Ranges dann ja über Objektgrenzen hinweg funktionieren.
Wenn bei euch jede Zeile ein Objekt ist, dann könnt ihr die Ranges nicht an die Objekte binden, wenn sie auch über die Objektgrenzen hinweg funktionieren sollen.Das sehe ich kritisch.
Eventuell wäre es sinnvoll zwei Arten von Ranges einzuführen, eine die an Objekte gekoppelt sind, also an die Zeilen und die Zeilen statisch einfärbt.
Statisch weil ein C++ Schlüsselwort wie z.B. while ja auch nach dem markieren mit der Maus und wieder los lassen ein Schlüsselwort bleibt.
Und eine extra Range die nur zum Markieren da ist.Wobei die Range zum Markieren dann beim Zeichnen die höhere Priorität hat, als die statischen Objektgebundenen Ranges.
-
Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.
-
hustbaer schrieb:
Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.
Sorry das ist Blödsinn.
Jedes Wort/Sonderzeichen als ein Objekt zu behandeln ist auch Unsinn.
Speicher dein Dokument als Liste von Zeilen.
Styleinformationen zusammen mit den Zeicheninformationen zu speichern ist auch eine Schlechte Idee.
-
gastantwort schrieb:
hustbaer schrieb:
Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.
Sorry das ist Blödsinn.
Das ist Blödsinn ... weil?
-
hustbaer schrieb:
gastantwort schrieb:
hustbaer schrieb:
Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.
Sorry das ist Blödsinn.
Das ist Blödsinn ... weil?
Denk mal darüber nach was passiert wenn du am Anfang der Datei dann was anfügst.
-
Wir suchen also eine Datenstruktur, bei der man:
* überall schnell große Teile einfügen und löschen kann
* überall schnell hinspringen kann (gehe zu zeile...)
* schnell sequentiell durch gehen kann, zum parsen
* noch was?
-
gastantwort schrieb:
hustbaer schrieb:
gastantwort schrieb:
hustbaer schrieb:
Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.
Sorry das ist Blödsinn.
Das ist Blödsinn ... weil?
Denk mal darüber nach was passiert wenn du am Anfang der Datei dann was anfügst.
Na dann dauert es ein wenig. Ist das so schlimm?
OK, zugegeben, das skaliert nicht beliebig.
Zeilen (nur) in einer Linked-List zu halten ist aber auch irgendwie Blödsinn.
Zumindest braucht man einen guten Index "in" diese Liste. Sonst wird das recht langweilig wenn der User mit "go to line" in die Mitte des Files springen will.
-
@NEEDE:
Ich denke ein leicht modifizierter B-Baum würde sich anbieten.Die Keys stören etwas, denn wenn man als Key die Zeilennummer verwenden will, dann müsste man bei jedem INSERT alle folgenden Zeilennummern updaten.
Andrerseits kommt so ein Baum auch gut ohne Keys aus, also einfach weg damit.
Jetzt stört nur noch, dass man - da man ja keine Keys mehr hat - erst wieder den ganzen Baum durchackern müsste, wenn man Zeile Nummer X sucht.
Das liesse sich allerdings umgehen, indem man in jeder Node die grösse "ihres" Teilbaums abspeichert (=Anzahl der Werte=Zeilen). Ich denke das sollte ohne all zu schlimmen Overhead bei INSERT/DELETE möglich sein.
-
hustbaer schrieb:
gastantwort schrieb:
hustbaer schrieb:
gastantwort schrieb:
hustbaer schrieb:
Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.
Sorry das ist Blödsinn.
Das ist Blödsinn ... weil?
Denk mal darüber nach was passiert wenn du am Anfang der Datei dann was anfügst.
Na dann dauert es ein wenig. Ist das so schlimm?
Ne das dauert nicht nur ein wenig, das ist extrem langsam, bei jedem gedrückten Zeichen musst du ein paar hundert kilobyte (für kleine Dateoen) im Speicher rumschieben und je größer die Datei offensichtlich desto langsamer. Und jetzt überleg mal wieviele Zeichen man in der Regel pro Sekunde/Minute hintereinander schreibt...
Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer
-
gastantwort schrieb:
Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer
Fail.
-
Das ist Blödsinn, da sich BLOBs üblicherweise nicht indizieren lassen.
