AW: Memo1.Text.Length erzeugt "Integer Overflow"
Zitat:
|
AW: Memo1.Text.Length erzeugt "Integer Overflow"
Könnte das hier nicht der Code von Length sein?
Delphi-Quellcode:
Setz doch einfach mal ein paar MessageBoxen einige Zeilen vor und einige nach Length. Irgendwo wird der Fehler dann sein denke ich.
function __StringLength(.... // Rückgabewert immer Integer
begin Result := PInteger(PByte(S) - 4)^; end; |
AW: Memo1.Text.Length erzeugt "Integer Overflow"
Ich frage mich eher was der Sinn ist. 3 Millionen Zeilen kann doch niemand jemals lesen. Bist du sicher, dass ein TSynMemo hier sinnvoll ist?
|
AW: Memo1.Text.Length erzeugt "Integer Overflow"
Interessant ist in dem Zusammenhang auch, dass für die Datenmenge 3 GB benötigt werden.
Das erscheint mir irgendwie deutlich zuviel zu sein. 3.000.000 Zeilen * 100 Zeichen = 300.000.000 Zeichen 3 GB ist irgendwie deutlich mehr. TSynMemo liefert doch eine Syntaxhervorhebung. Wird die benötigt? Was ist eigentlich die ursprüngliche Aufgabenstellung, für die die Anzahl der Zeichen ermittelt werden soll? Eventuell gibt es ja 'ne andere Zählmöglichkeit. |
AW: Memo1.Text.Length erzeugt "Integer Overflow"
100 Zeichen á 2 Byte
und dann noch die Speicherfragmentierung, wenn man jede Zeile einzeln speichert. TMemo ist auch nicht besser, denn da wird das in einem Speicherblock abgelegt und man braucht das GB auch an einem Stück, was unter 32 Bit praktisch nahezu unmöglich ist, selber mit aktiver 3 oder 4 GB-Erweiterung. Allerdings könnte man sich auch fast fragen, warum überhaupt alle Zeilen unbedingt gleichzeitig in den Speicher müssen. Will sich das wirklich jemand ALLES ansehn? Entweder die Daten filtern und nur eine menschenlesbare Menge anzeigen, oder es gibt auch Edits, die nur den jeweils grade sichtbaren Teil laden. |
AW: Memo1.Text.Length erzeugt "Integer Overflow"
Liebe DP-Gurus (das ist absolut positiv gemeint!!!),
das war ja klar das die übliche Frage "ist es überhaupt sinnvoll..." aufkommt... ;-) Dann erklär ich das mal: Ja, ist es, denn es handelt sich bei dem Programm um einen "Editor", dessen Spezialgebiet die Analyse, Filterung und Umstrukturierung von Textdatei-basierten Daten ist. Es ist nicht "just another Quelltexteditor"... ;-) Er wird ständig unseren Bedürfnissen angepasst und ist ein unverzichtbares Tool geworden, wenn man "mal schnell was in den Daten nachsehen" oder Dateiformate "umbasteln" muss. Aufgrund der Historie de Programms und wegen der Performance muss dabei alles im Speicher ablaufen. Da ich vor einer Schulung Beispieldateien zusammen suchen wollte, die z.B. demonstrieren, welch große Dateien man damit bearbeiten kann, bin ich über das Length-Problem gestolpert. Es wird dabei übrigens String.Length (ein String-Helper) benutzt. Auch die Funktion Length() packt's ab einer bestimmten Größe nicht mehr, obwohl der String die Daten aufnehmen kann - es waren Übrigens rund 1,3 G Zeichen. Der Vorschlag, die Länge selbst in einer Loop über die Zeilen zu bestimmen, erschien mir zunächst performance-technisch völlig ungeeignet, da bei jeder eingabe eines Zeichen im Editor diese Zahl neu angezeigt - und damit auch berechnet werden muss. ABER: Ich hab's trotzdem ausprobiert und es dauert auch bei 3 Mio Zeilen nur den Bruchteil einer Sekunde! Damit ist also mein Problem gelöst. Vielen Dank allen! Gruß Freejay |
AW: Memo1.Text.Length erzeugt "Integer Overflow"
Zitat:
Du solltest aber beachten, daß Text für jede Zeile ein CRLF anfügt. Dadurch ist die Length(Text) nicht identisch mit Sum(Length(Lines[I]))! |
AW: Memo1.Text.Length erzeugt "Integer Overflow"
@Uwe
Wie wäre es denn damit?
Delphi-Quellcode:
function TextLength(sl : TStrings) : Cardinal;
var i : Cardinal; k : Cardinal; begin Result := 0; k := Length(sLineBreak); for i := 0 to sl.Count - 1 do Inc(Result, Length(sl[i]) + k); end; |
AW: Memo1.Text.Length erzeugt "Integer Overflow"
Zitat:
|
AW: Memo1.Text.Length erzeugt "Integer Overflow"
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:32 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz