Variable used without being declared - nach dem compilieren

Zitat von Racer

Eigentlich sollte es keinen Unterschied machen ob ich "if $test then" oder "if $test = True Then" schreibe, außer das es kürzer ist! Aber wenn was nicht geht und man sich schon die Haare rauft probiert man alles was es gibt - könnte ja doch was dran sein und ja, da beginnt man wieder an den Weihnachstsmann zu glauben, hauptsache es funktioniert

Jaein, (folgendes ohne Gewähr) man sollte es meinen aber ich meine mich erinnern zu können das es Unterschiede zwischen Windows true/false und AutoIt true/false geben kann, weshalb man mir mal empfohlen hat niemals auf true oder false zu prüfen, sondern immer if X then bzw if not X then zu nutzen.

Naja es ist eigentlich überhaupt kein Problem per If $test = True Then zu verzweigen.
Es wird damit nur implizit eine weitere Verarbeitungsstufe eingezogen.
Was meine ich damit?:
Eine If-Verzweigung in AutoIt ist prinzipiell so aufgebaut: If [Bool-Ausdruck] Then.
Würde man für den Ausdruck eine Variable einsetzen dann hätte man direkt ein  If True/False Then.

Wenn man stattdessen If $test = True Then schreibt, dann hat man einen Zwischenausdruck, der erst ausgewertet werden muss, dessen Ergebnis in eine Zwischenvariable gespeichert werden muss und diese dann in der If-Verzweigung eingetragen wird.

Also der Ausdruck $test = true wird erst ausgewertet und ergibt z.B. als Ergebnis den boolschen Wert true. Dieses Ergebnis wird nun im Speicher zwischengesichert und für die If-Bedingung verwendet.

Man hat also einen Zwischenschritt eingefügt der prinzipiell entbehrlich ist.

Das ist aber im Grunde überhaupt nicht schädlich. Der Einfluss auf die Performance ist gleich 0 (Compiler würden es i.d.R. auch wegoptimieren) und das Ergebnis ist genau das gleiche.
Hingegen hat die lange Variante einen entscheidenden Vorteil:
Es ist so klarer was eigentlich gewollt ist. Jeder sieht sofort, dass die Variable true sein muss damit es weitergeht. Bei der kurzen Variante ist das, gerade für Neulinge, nicht sofort ersichtlich.

Daher würde ich eher dazu plädieren die längere Variante zu nehmen.

Zitat von Moombas

Unterschiede zwischen Windows true/false und AutoIt true/false

Das wäre bemerkenswert - ein Bit kann nur exakt 2 verschiedene Werte annehmen.
Ich überlege mir gerade wie da überhaupt Unterschiede implementiert werden könnten.

Zitat von AspirinJunkie

Das wäre bemerkenswert - ein Bit kann nur exakt 2 verschiedene Werte annehmen.
Ich überlege mir gerade wie da überhaupt Unterschiede implementiert werden könnten.

Straf mich Lügen (ich kann das auch falsch im Gedächtnis haben) sber ich meine jemand hatte hier mal geschrieben, das Windows False dem Autoit True entsprechen kann und andersrum, sprich 1 und 0 vertauscht sind (kann auch Return Code bedingt gewesen sein).

Wie gesagt, bin mir unsicher.

Was ist denn "Windows False"?
In der Windows-API wird der Typ bool in der Datei windef.h folgendermaßen definiert: typedef int BOOL;.
Windows false ist also ein integer mit dem Wert 0.

Was ist ein "AutoIt False"?
Im alten Quelltext von AutoIt wird ebenso bool verwendet.
Die Definition dort wird (für den Fall dass kein msvc-compiler verwendet wird) aus der windef.h gezogen - und dort ist der Typ, wie wir bereits wissen, als typedef int BOOL; definiert.

Ich sehe daher nicht wo sich diese beiden unterscheiden würden.

Ok, dann habe ich das ggf. falsch im Kopf. Dann sorry für die Verwirrung.

Aber warum funktioniert bei ihm das Skript nun, wenn man = True weg lässt?

Ist das so?
Wir haben bisher nur ein paar Codeschnipsel gesehen und keiner von uns kann das beschriebene daher reproduzieren.
Es ist eher wahrscheinlich, dass der Fehler ganz anders gelagert war. Evtl hatte er nen Schreibfehler alla $testt drin oder so, den er dann mit ausgebügelt hat ohne es zu merken etc.

Kurz: Ich sehe noch nicht, dass dies wirklich zusammenhängt. Dafür bräuchte man ein reproduzierbares Minimalskript.

Ich würde davon abraten, bool Variablen mit == True zu vergleichen.

1. Es ist sprachenabhängig. Es gibt Sprachen, wo es anders definiert ist. In diesem Fall kann es dir auch passieren, dass irgendein Treiber nicht die Definition der windef.h nutzt, sondern was eigenes und du das als Struct bekommst o.ä. ... Also ich wäre eher vorsichtig.

2. In manchen Sprachen ist True nicht als 1 definiert, sondern als "nicht 0", also nicht false. Deshalb kann es passieren, dass dort z.B. eine 3 zurückgegeben wird. Dann würde der Test mit ==True fehlschlagen, weil True ja intern 1 wäre und 1!=3

3. In vielen Sprachen kann man in Conditions auch zuweisungen machen (auch in C). if($isCorrect == True) und if($isCorrect = True) schaut fast gleich aus, das eine ist aber immer True und ändert auch noch die Variable zu True und das nur durch ein vergessenes/beim tippen nicht richtig getroffenes =.

4. Wenn man Variablen richtig benennt, also mit $bSomething oder besser noch $bIsSomething, dann sieht man es ah sofort.

Für mich sind das genug Gründe, direkt den Boolean zu schreiben und nicht unnötigen extra Code zu haben, der nichtmal wirklich was bringt... Zu großes Risiko für einen fast nicht existierenden Vorteil.

Zitat von Kanashius

Ich würde davon abraten, bool Variablen mit == True zu vergleichen.

Jetzt bin ich geplättet: Du rätst davon ab, eine Boolsche Variable mit einem Boolschen Wert zu vergleichen?!

Muss man das verstehen?

Hättest du gesagt, du rätst davon ab mit dem AutoIt-Scheiß von Variant-Datentyp zu vergleichen - das könnte ich nachvollziehen - aber hier fehlen mir die Worte.

EDIT:

Zitat von Kanashius

In manchen Sprachen ist True nicht als 1 definiert, sondern als "nicht 0", also nicht false. Deshalb kann es passieren, dass dort z.B. eine 3 zurückgegeben wird. Dann würde der Test mit ==True fehlschlagen,

Hier widersprichst du dir selbst: Wenn die Variable den Wert "1" oder "3" (oder jeden anderen Wert ungleich True/False) hat ist sie keine Boolsche Variable!

Die missbräuchliche Verwendung in Bool-Variablen ist wiederum dem Variant-Datentyp geschuldet. - Was am Anfang durchaus hilfreich scheint, erweist sich immer mehr als zweifelhafte Lösung.

Wenn du einen fixen DatenTyp "Bool" hast und den selber befüllst,... wird es natürlich funktionieren.

Ich hab mich vmtl. falsch Ausgedrückt. In python z.B. kann man den return "type" angeben, kann aber trotzdem etwas anderes zurückgeben. An so etwas hab ich eher gedacht. Aber das ist ja quasi der Variant-Datentyp, den du meinst.

Punkt 3+4 sind für mich wichtiger, das andere ist mehr so ein vorsichtig sein. In C gibt es recht viele "hacks/tricks", an die man nicht denkt, manche aber verwenden. Durch sowas kann man ja z.B. Integer zu Bool auf eine Art konvertieren, dass True am Ende nicht 1 ist, da es am Ende wie von AspirinJunkie erwähnt nur ein Integer ist. Ich denk da z.B. an einen Fehler-Wert in irgend einem struct und jemand kopiert den wert als memory Operation einfach rüber in ein anderes struct, wo es dann als boolean verwendet wird. Sollte man meiner Meinung nach nicht tun, aber wer weiß, auf was für Ideen manche kommen. Weil genaugenommen entspricht es halt der Specification, dass 0 False ist, alles andere True. Warum also nen extra code-abschnitt einfügen um alle andern Werte auf 1 zu setzen. Deshalb mein Argument: Besser vorsichtig sein, wer weiß, was low-level dort zusammengebastelt wurde... Es ist von compiler/memory-sicht ein integer. Nur aus programmier sicht halt nicht.

Deshalb geben viele Compiler auch eine Warnung, wenn man $bSomething == True schreibt.

Zitat von Racer

Könnte sich im Editor ein nicht-sichtbares Zeiten eingeschlichen haben (z.B.: Shift + Space) den der Interpreter ignoriert, aber nach dem kompilieren dann als zusätzliches Zeichen bei der Variable wahrgenommen wird?

Um das zu prüfen, könntest Du den Quellcode mal mit Notepad++ öffnen und dort die Option nicht druckbare Zeichen anzeigen aktivieren.

Racer : EDIT

Bei aktuellen Versionen von Notepad++ findet man folgende Einstellung :