Wie würdet ihr einen Editor schreiben? Jede Zeile als ein Objekt?

hustbaer

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.

hustbaer

@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

volkard

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Wutz

Das ist Blödsinn, da sich BLOBs üblicherweise nicht indizieren lassen.

volkard schrieb:

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Haben alle deine zweiundzwanzigtausend Posts so wenig Inhalt?

hustbaer

@volkard:
Hihi, ja.

@Wutz:
Wieso sollte man einen BLOB nicht indizieren können?

std::vector<char> blob; // der BLOB
std::vector<size_t> lineStartOffsets; // der Index

hustbaer

gastantwort schrieb:

volkard schrieb:

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Haben alle deine zweiundzwanzigtausend Posts so wenig Inhalt?

Ach der Inhalt passt schon. Du hast halt Unsinn gepostet.
Googel vielleicht selbst mal nach GapBuffer, und lies nach was das ist.

Vielleicht wird dir dann auffallen, dass dabei eben gerade nichts in Zeilen unterteilt wird. Sondern der ganze Text in einem grossen Stück abgelegt wird.

Nur dass man eben nicht Zeichenweise einfügt, sondern gleich Platz auf Vorrat schafft, damit man schnell weitere Zeichen dazutippen kann.

hustbaer schrieb:

gastantwort schrieb:

volkard schrieb:

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Haben alle deine zweiundzwanzigtausend Posts so wenig Inhalt?

Ach der Inhalt passt schon. Du hast halt Unsinn gepostet.
Googel vielleicht selbst mal nach GapBuffer, und lies nach was das ist.

Vielleicht wird dir dann auffallen, dass dabei eben gerade nichts in Zeilen unterteilt wird. Sondern der ganze Text in einem grossen Stück abgelegt wird.

Falsch, jede Zeile ist ein GapBuffer. Dass die Dokumente zeilenbasiert gemanagt werden steht außer Frage. Du hast dich offenbar nicht mehr als 5 Minuten mit dem Thema beschäftigt, sonst wärst du wohl auch gar nicht mit deinem KindergartenBLOB gekommen

hustbaer

gastantwort schrieb:

hustbaer schrieb:

gastantwort schrieb:

volkard schrieb:

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Haben alle deine zweiundzwanzigtausend Posts so wenig Inhalt?

Ach der Inhalt passt schon. Du hast halt Unsinn gepostet.
Googel vielleicht selbst mal nach GapBuffer, und lies nach was das ist.

Vielleicht wird dir dann auffallen, dass dabei eben gerade nichts in Zeilen unterteilt wird. Sondern der ganze Text in einem grossen Stück abgelegt wird.

Falsch, jede Zeile ist ein GapBuffer. Dass die Dokumente zeilenbasiert gemanagt werden steht außer Frage. Du hast dich offenbar nicht mehr als 5 Minuten mit dem Thema beschäftigt, sonst wärst du wohl auch gar nicht mit deinem KindergartenBLOB gekommen

ROFL
Jede Zeilt ist ein Gap-Buffer = der grösste Unsinn den ich seit langem gelesen habe

hustbaer schrieb:

gastantwort schrieb:

hustbaer schrieb:

gastantwort schrieb:

volkard schrieb:

gastantwort schrieb:

Im übrigen benutzt man auch keine verkettete Liste für die Zeilen sondern auch ein indexbasiertes array. Google mal nach GapBuffer

Fail.

Haben alle deine zweiundzwanzigtausend Posts so wenig Inhalt?

Ach der Inhalt passt schon. Du hast halt Unsinn gepostet.
Googel vielleicht selbst mal nach GapBuffer, und lies nach was das ist.

Vielleicht wird dir dann auffallen, dass dabei eben gerade nichts in Zeilen unterteilt wird. Sondern der ganze Text in einem grossen Stück abgelegt wird.

Falsch, jede Zeile ist ein GapBuffer. Dass die Dokumente zeilenbasiert gemanagt werden steht außer Frage. Du hast dich offenbar nicht mehr als 5 Minuten mit dem Thema beschäftigt, sonst wärst du wohl auch gar nicht mit deinem KindergartenBLOB gekommen

ROFL
Jede Zeilt ist ein Gap-Buffer = der grösste Unsinn den ich seit langem gelesen habe

Hm, tatsächlich? Der größte Unsinn den ich in letzter Zeit gelesen hab war das hier:

hustbaer schrieb:

Schmeiss alles in einen Blob, und mach dann Indexe/Lookup Tabellen für Dinge wie Zeilenumbrüche, Farben oder markierte Bereiche.

Aber mal ernsthaft, nachdem du dich inzwischen schon 7 Minuten mit dem Thema befasst hast traust du dich zu so einer Aussage? Lies erstmal ein bisschen.

volkard

Lies Seite 65, letzten Absatz, und Seite 68.

Anno 1991 hätte ich auch GapBuffer genommen. Moment mal, 1991 *habe* ich einen GapBuffer genommen. Das war damals angemessen. Wenige k Text ohne Formatierung, wenig RAM, lahmer Prozessor, schwache Sprache.

Da ich nicht glaube, daß Du die letzten 20 Jahre total verpaßt hast, nehme ich an, Du hast heute was ergooglet und willst jetzt partout recht behalten. Keine Chance, weil Du ganz weit daneben liegst. Bist auf einen ein wenig unmodernen Wikipedia-Artikel reingefallen. Und hast nichtmal unten den Link zu Rope gefunden. Übrigens solltest Du beim Rope-Artikel die Fußnote 1 verfolgen.

Soll nicht heißen, daß man Ropes verwenden müßte. Aber in ihrer Anwesenheit sind GapBuffers schonmal tot.

SeppJ

hustbaer schrieb:

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.

Ziemlich genau das habe ich übrigens neulich mal implementiert, als Lösung zu diesem Thread:
http://www.c-plusplus.net/forum/284342

Ist wie ein set mit indiziertem Zugriff. Derzeit sortiert es noch intern die Datenelemente (weil's für meine Anwendung so gedacht war), aber das sollte sich anpassen lassen. Falls Interesse besteht kann ich das hochladen.

volkard

hustbaer schrieb:

@NEEDE:
Ich denke ein leicht modifizierter B-Baum würde sich anbieten.

Das vermute ich auch. Weil man dann alles in bequeme Seiten zerhackt hätte. Man könnte auch Dateien bearbeiten, die gar nichts ins RAM passen. Man könnte Änderungen anhängen, statt die alten Daten zu ändern. Und das könnte harmonisch mit dem Baum zusammenwirken, damit man nicht lauter Ebenen ineinanderschachteln muß, Item (selektierbare Range) in Zeile (GapBuffer) in Seite (verkettet Liste) in Datei (GapBuffer von Seitenzeigern) und dazu orthogonal eine Speicherverwaltung, die Elemente in der Datei und im Ram verwaltet, die durchaus zum selben Dokument gehören können, und darunter die Dokumentverwaltung und das Rausschreiben des Rams in die Datei. Oder so, man kann sich ja soo toll verhaspeln und hat am Ende etwas völlig Unwartbares.

hustbaer

@gastantwort:
Guck dir bitte den Code von Scintilla an.

volkard schrieb:

Man könnte auch Dateien bearbeiten, die gar nichts ins RAM passen.

Sowas hab ich schon zu DOS Zeiten geschrieben. Damals hatte ich aber auch noch keine Ahnung, wie man Speicher auf dem Heap anlegt. Mein Hexeditor konnte dann auch nur so ca. 10000 Zeichen ändern und nichts einfügen oder löschen. Aber zum Savegames hacken hats gereicht, die haben sowieso nicht mehr richtig funktioniert, wenn man sie größer oder kleiner machte. Und ich konnte ein Textfile etwas schneller als der Norten Commander durchsuchen.

NEEDE schrieb:

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?

Bereiche einfärben kann.
Bereiche ausblenden kann -> Klammerfunktionen bei Programmiersprachen ausblenden