Beiträge von alpines

Zitat von Mikki

Ich weiß auch nicht wie ich die Dateien an sich vergleichen soll. Ist StringCompare überhaupt das Mittel zur Wahl?

Hast du denn mal einen Blick in die Dokumentation geworfen was StringCompare hinter den Kulissen treibt?

Wenn du zwei Dateien vergleichen möchtest und nur wissen willst, ob sie identisch sind, kannst du sie mit FileRead einlesen und einfach mit "=" oder "==" vergleichen.

Dann weißt du, dass es einen Unterschied gibt. Willst du allerdings wissen wo der Unterschied ist, musst du auf Differenzen prüfen, das ist etwas komplizierter je nach dem wie detailliert man es haben will.

Zitat von Mikki

FileOpen($Path & $aFileList)

Du übergibst da das gesamte Array statt einen Index.

Zitat von Musashi

Du solltest ggf. aber darauf achten, dass es einen Unterschied zwischen = und == gibt !

(google mal nach AutoIt vergleichende Operatoren)

Das ist ein eher ungewöhnliches Beispiel. Der 'klassische' Unterschied zwischen = und == ist, dass die doppelte Variante case-sensitiv ist.

Ich glaube, dein Beispiel ist eher ein Nebenprodukt.

Local $bResult
$bResult = "asd" = "aSd"
ConsoleWrite('@@ Operator =   -> ' & $bResult & @CRLF)
$bResult = "asd" == "aSd"
ConsoleWrite('@@ Operator ==  -> ' & $bResult & @CRLF)

Zitat von Racer

Danke - wäre ich nie darauf gekommen das es auch so geht!

Na klar geht das, das ist auch an machen Stellen sehr sinnvoll damit die If-Abfrage nicht überladen wird.

Einfach die Abfragen davor machen und in Variablen speichern und später in der If-Abfrage nur mit den Variablen arbeiten die die Unterbedingungen darstellen.

Was hast du mit deiner armen Platte angestellt

Zitat von eukalyptus

Heißt das nun, dass NTFS doppelte Dateien nur einmal speichert!?

Da bin ich mir ehrlich gesagt nicht sicher, ich glaube, dass das nicht der Fall ist. Denn das wäre das erste Mal, dass ich davon höre (in Bezug zu NTFS).

Ob ChkDsk Dateien gegenseitig auf Duplikate überprüft weiß ich auch nicht, vielleicht hast du Inkonsistenzen im MFT deiner NTFS-Partition?

Es könnte ja sein, dass dort die Daten mehrfach verlinkt sind obwohl sie nur einmal auftauchen, wenn ChkDsk die Einträge durchgeht und prüft ist ja kein Fehler da, da die Dateien und Sektoren alle existieren.

Eine Überprüfung ob sich Sektoren gegenseitig überschneiden würde ja bei einer 1 TB Platte Ewigkeiten dauern, deshalb vermute ich stark, dass ChkDsk das nicht überprüft.

Es könnte auch sein, dass beim Umbenennen oder Kopieren von Daten der Kopiervorgang einfach abgestürzt ist, weil die Festplatte überlastet wurde oder etwas anderes dazwischengekommen ist und die alten Dateien nicht "unlinked" wurden.

Ist auf den anderen Partitionen der HDD auch Daten drauf die in irgendeinerweise verlinkt sein könnten? Vielleicht hast du ja Querverweise (Verknüpfungen oder ähnliches) bei der die Größe der Dateien im vollen Umfang mitgerechnet wird?

Lass dir mal zur Sicherheit mit WinDirStat oder einem ähnlichen Tool die Daten anzeigen, damit du neben den Boardtools von Windows und Linux noch eine dritte Meinung hast.

Zitat von Professor Bernd

Warum habe ich den Ansatz der binären Suche nicht weiterverfolgt? Offen gesagt, weil es mir zu hoch ist. (Respekt für alle, die das handhaben können!)

Das ist kein Problem, wenn die Suche auch auf schwächeren CPUs in einer akzeptablen Zeit funktioniert kannst du es ja auch so belassen. Es ist ja nicht so, als ob die Calltips in nächster Zeit explodieren werden.

Die Ansätze für schnellere Suchen solltest du im Hinterkopf behalten, dazu musst du nicht unbedingt über Laufzeitklassen bescheid wissen aber immer was in der Tasche haben um performant suchen zu können.

Der Tag wird kommen, an dem du eine schnelle Suche brauchen wirst.

Zitat von TJF

"Compile With Options" sehe ich auch nirgendwo.

Rechtsklick auf ein Script. Vielleicht brauchst du dafür noch SciTE4AutoIt.

Zitat von TJF

Kann man jetzt eigentlich auch in der 64 Bit Version 32Bit-Programme kompilieren (wie anders herum)?

Ja, nimm einfach die Option "Compile With Options" im Kontextmenu oder direkt Compile (x64). Die "Compile Script" Option ist die die die Version kompiliert die du beim Installer angegeben hast.

Im Grund nimmt sich da bei AutoIt nichts, ich glaube die 64Bit Variante erlaubt einen tieferen Stack (für Rekursionen und derlei Spielereien).

Zitat von Professor Bernd

Seid ihr beide der Meinung, dass Dictionarys schneller sind, als Arrays? Ist irgendwas im fühlbaren Bereich, oder nur messbar?

Bei 4000 Einträgen kannst du davon ausgehen, dass es schneller ist und ein kleiner und schlampiger Test zeigt es das bei mir auch auf dem System.

Selbst wenn auf den ersten Index zugegriffen wird dauerts doppelt so lange wie bei einem Scripting Dictionary.

Das sollte auch nicht weiter überraschen, da der Interpreter die Schleifen interpretieren muss wohingegen beim Objekt einfach der native Code dafür ausgeführt wird.

Zitat von Professor Bernd

Huah, coole Idee! 27 Arrays erstellen, ob das einen Geschwindigkeitsgewinn bringt?

Du kannst das auch in einem Array haben, brauchst keine 27 Arrays. AutoIt unterstützt auch 10D-Arrays.

Aber wenn du den gesamten Funktionsnamen hast dann nimm einfach ein Dictionary. Das sollte mehr als ausreichen.

Zitat von chesstiger

Vom Gefühl her würde ich ein Dictionary oder eine HashTable ausprobieren. Die weisen ja auch quasi konstante Zugriffszeiten auf.

Was ist wenn jemand "Msg" tippt aber nicht den Rest? Du müsstest trotzdem über alle Keys iterieren.

Das gesamte Array zu iterieren ist quatsch, das dauert zu lange und du kannst bei besserer Genauigkeit (wenn MsgB statt M getippt wird) keine Performance rausholen.

Das wirklich performant zu gestalten ist eine Wissenschaft für sich, da gibt es wirklich so viele Wege wie Sandkörner am Meer.

Was mir spontan einfällt ist ein Array zu nutzen dessen Indizes ein Buchstabe aus dem Alphabet ist. Daraus holst du dir dann ein anderes Array und gehst es durch oder verschachtelst immer weiter.

Das tolle daran ist, du hast eine konstante Zugriffszeit auf den Anfangsbuchstaben und kannst so (bei gleichmäßiger Verteilung) 25/26 der Ergebnisse vernachlässigen, da sie eh nicht in Frage kommen.

Um ehrlich zu sein würde ich dazu wirklich gerne mal einen Geschwindigkeitsvergleich sehen indem man mal alle Möglichkeiten durchcodet und vergleicht!

Mal so am Rande gefragt, was hastn du für 'ne Systemplatte? SSD oder HDD?

Zitat von Tyzer

bei "Autoit 1073741819" ohne das Minus schon das hab ich auch wenige Minuten nach dem posten gemerkt.

Das liegt daran, dass Google eine gewisse Syntax beim Suchen anwendet. So steht das Minus dafür, dass dieses Wort NICHT enthalten sein darf.

Wenn du nach der Zahl suchen willst dann setz nur die Zahl in Gänsefüßchen, dann klappt das auch.

Zitat von Tyzer

Mein Programm ist leider sehr lang 30.000 Zeilen sodass ich den Code hier nicht posten kann

Dann können wir dir auch nicht helfen.

Solltest du es schaffen den Fehler zu isolieren, so dass wir ihn reproduzieren können, vielleicht.

Meistens ist ein solcher Crash bedingt durch Nullpointer Exceptions bei Ausführung von DLLs.

Ja, zerpflücken darfst du selber. Entweder mit enfachen Stringfunktionen oder mit Regex.

Zitat von hipfzwirgel

Verstehe ich es richtig, dass ein Array in einer Funktion auch nur dort gilt, vorausgesetzt es existiert
kein weiteres mit gleichem Namen im Programm, auch ohne das Schlüsselwort Local?

Korrekt. Dadurch wird die Konsistenz von Scopes (Gültigkeitsbereichen) durchgesetzt.

Wird eine lokale Variable mit dem gleichen Namen einer globalen Variable erzeugt, so ist die globale Variable innerhalb des Scopes nicht mehr ansprechbar. Alle Referenzen in dem Scope (nach der Deklaration versteht sich) richtigen sich auf die lokale Variable.

Zitat von hipfzwirgel

Aber warum wurde der Fehler ausgegeben nachdem ich, wie in Zeile 26, das Local einfügte? Hast du da eine Idee?

Ich kann so leider nur spekulieren, bastel doch bitte ein Skript, dass ich ausführen kann welches den Sachverhalt reproduziert.

Dein Skript an sicht wird ja keinen Fehler schmeißen, da die Funktion noch nicht einmal aufgerufen wird.

Der Au3Checker kommt bei einigen Fehlern sehr stark durcheinander und gibt die Fehlermeldungen an den falschen Stellen aus, obwohl die Fehler teilweise komplett woanders liegen.

Ich hatte das schon oft genug, deshalb kann ich da nicht helfenn wenn ich es nicht reproduzieren kann.

Das Skript scheint ja ok zu sein.

Zitat von hipfzwirgel

Nachdem ich später dem $aArray1 das Schlüsselwort Local vorangestellt habe(damit es eben nur in dieser Funktion gilt),

Existiert keine Variable mit dem selben Namen in dem darüberliegenden Scope wird immer eine neue mit dem kleinsten Scope erstellt.

Du brauchst da nicht unbedingt ein Local. Es hilft aber beim Lesen des Codes.

Dein Skript ist außerdem alles andere als vollständig. Du erzeugst ein Array mit einem Index $arBase greifst aber in Zeile 38 auf den 2. Index zu, obwohl es nur die Größe eins hat.

Einen anderen Fehler kann ich nicht erkennen.

Übrigens ist das "löschen" von Variablen nicht notwendig. Wenn du den Scope verlässt, für das sie definiert sind, werden sie automatisch gelöscht, außer es sind statische Variablen.