Beiträge von Marthog

In AutoIt wird der lesbare Code in Tokens zerlegt, das sind u.A. die einzelnen Funktionsnamen, Strings, Zahlen, Variablenname, Keywords, Operatoren (+ - , [ ...) Diese Tokenliste wird dann Stück für Stück eingelesen, dabei muss aber während der Ausführung bestimmt werden, in welcher Reihenfolge die Befehle ausgeführt werden.

Lua z.B. hat eine assemblerähnliche Sprache, in die das erstmal übersetzt und dann in bytecode weiterumgewandelt wird. Dieser Bytecode wird dann interpretiert.
Dadurch kann Befehl für Befehl abgearbeitet werden und der Interpreter muss nicht mehr die Reihenfolge bestimmen.

Zudem verhalten sich die lokalen Variablen anders. In AutoIt gibt es eine Liste mit Variablennamen und Werten, die bei jedem Verwenden einer Variable durchsucht werden muss. In Lua werden die lokalen Variablen zu Indices auf dem Stack und können dadurch schneller wieder ausgelesen werden.
Außerdem wird Lua ein bisschen optimiert, sodass aus den 7*(5+3) vor der Ausführung der Wert 65 berechnet werden würden.

Java funktioniert so ähnlich, aber hat festgelegte Typen und wahrscheinlich ist der Optimierer hier ausschlaggebend, denn bei einer Programmanalyse würde er herausfinden, dass die innere Schleife absolut unnütz ist, denn da wird bis 100000000 gezählt, die Variable aber außerhalb dieser Schleife nie verwendet. Dazu habe ich auch etwas in den von dir verlinkten Thread geschrieben am Beispiel C++, das auch sagenhafte 0 Millisekunden gekommen ist.

Der Style $WS_POPUP entfernt Rand und Titelleiste. $WS_POPUPWINDOW ist so ähnlich, lässt aber einen 1 Pixel breiten Rand.

Ich verstehe nicht genau, was du machen willst.
Wenn du die html-Datei öffnen willst, verwende ShellExecute. Der Befehl funktioniert wie ein Doppelklick auf die Datei.

EDIT: gnarf

Herzlichen Glückwunsch!

Warum über Schnittpunktberechnung? Bei einem Rechteck ist der Mittelpunkt immer auf Höhe der halben Seitenlängen. Der vierte Punkt ist dann auch egal.

M: Mittelpunkt
A: erster Punkt
AB: Strecke von A zu B: B-A
AD: Strecke von A zu D: D-A

M = A + (AB + AD)/2

Herzlichen Glückwunsch!

Ich habe eben gerade mal meinen eigenen, sich in Entwicklung befindenden, AutoIt-Compiler ausprobiert.
Erst ergab sich kein Geschwindigkeitsgewinn gegenüber AutoIt, nach einer Optimierungsmaßnahme sank die Dauer aber auf ca. 900 ms.
Zu der Zeit brauchten die AutoIt-skripte ca. 9140 ms, also ungefähr 10-fache Geschwindigkeit.

Zum Vergleich: Mein PC kommt mit AutoIt auf 17388.64 ms.

#include <chrono>
#include <iostream>


using namespace std::chrono;


int main()
{
	double diff = 0.0;
	for (int a=1; a<=4; ++a)
	{
		high_resolution_clock::time_point timer = high_resolution_clock::now();
		int i=0;
		while (i!=100000000)
			i += 10;


		duration<double> time_span = duration_cast<duration<double>>(high_resolution_clock::now() - timer);
		diff += time_span.count();
		std::cout<<a<<" Durchlauf: "<<time_span.count()*1000<<"ms\n";
	}
	std::cout<<"Durchschnitt: "<<diff/4*1000<<" ms\n";
}

Zitat von x0r

bei ner Datei mit 1.86mb Größe dauert meins um die 49sec.

Deine Lösung ist auch denkbar ungünstig, da:
1. Für _FileCountLines wird die Datei gelesen und gezählt.
2. Für FileReadLine wird ein Teil der Datei eingelesen, nach dem Zeilenende gesucht und sie dann geschlossen.
3. Zudem verwendest du viele Funktionen, die die Lesbarkeit deutlich erschweren.
4. Es wird abwechselnd gelesen und geschrieben, Ein- und Ausgabe muss also eine andere Datei sein.

Die Methode von Blowcake ist da deutlich besser.

Die, von AspirinJunkie hat natürlich den Vorteil, dass es nicht nur schnell ist, sondern die Dateigröße nicht für die Geschwindigkeit relevant ist, und auch Arbeitsspeicher gespart wird. Man kann z.B. auch 10 GB große Dateien bearbeiten, auch mit einem 32-bit System.

Zitat von J@ik

@m-obi - Da fragst du den falschen^^ Ich nehm(in autoit) halt immer Dim

Davon kann ich abraten, denn Dim kann sich genauso wie eine Variable, die ohne vorherige Deklaration verwendet wird, unterschiedlich verhalten.

Wie man sieht, wird $bar beim ersten Aufruf von Foo lokal erstellt und nach Funktionsende gelöscht. Danach exisitert aber die globale Variable $bar und diese wird verändert. So kann es vorkommen, dass ein Fehler auftritt, aber man an der falschen Stelle nach der Ursache sucht.
Ich mache das bei größeren Projekten immer so: Globale Variablen werden außerhalb einer Funktion mit Global, in Funktionen werden alle Variablen mit Local deklariert. Leider ist AutoIt, was die Variablendeklaration angeht nicht besonders einheitlich.

Im Prinzip kann Irrlicht in allen Windows-Standart-GUIs als Child eingebunden werden, also auch in AutoIt und ich habe das auch schonmal testweise gemacht. Damals habe ich aber nicht die Irrlicht-UDF verwendet, sondern eine eigene DLL geschrieben.

Bei der Irrlicht-UDF scheint die Funktion aber nicht vorhanden zu sein.

Grundsätzlich gilt: Was der Prozessor lesen kann, können auch manche Menschen lesen. Das macht vollständigen Schutz unmöglich. Beim Sichern des Codes ist es hauptsächlich wichtig, es so schwer zu machen, dass die Skriptkiddies es nicht mehr schaffen, also die Programme und Tutorials nicht mehr reichen.

Wenn du dir das mal genau anguckst und z.B. einen sehr großen Button erstellt, siehst du dass der 3D-Effekt nur ein Trick ist, indem der Button in zwei Farben eingefärbt ist. Drückt man ihn, wird die eine Farbe verändert und die Grenze verschiebt sich weiter nach unten.
Wenn man genau hinsieht, erkennt man, dass viele Elemente nach der gleichen Methode funktionieren.
Untersucht man alle Elemente, erkennt man, dass diese recht einfach gehalten sind, aber trotzdem noch gut aussehen, und die Effekte alle nur einfache Tricks sind. In Anbetracht der Tatsache, dass der Text sowieso erst beim Erstellen gezeichnet wird und das GUI auch für größere Auflösungen funktionieren soll, ist neue Generierung praktischer als vorher erstelte Bilder. Der Haken von Checkboxes und die Pfeile von Scrollbars sind aber vielleicht auch als Bild gespeichert.

%d und %i sind gleich.
In C gibt es noch die Funktion scanf, die nach der gleichen Syntax funktioniert, wie printf, nur wird eingelesen. Dabei ist %d immer dezimal, bei %i kann auch oktal oder hexadezimal eingelesen werden. Scanf ist in AutoIt aber nicht enthalten.

glut.h gehört zu OpenGL. Du musst es schon installieren und auch gegebenenfalls den Pfad in den projectsettings eintragen.

Es reicht so:

extern "C" __declspec(dllexport) int Summe(int a, int b)
{
   return a+b;
}

$hDll = DllOpen(@ScriptDir & "\Dll.dll")
$ret = DllCall($hDll, "int:cdecl", "Summe", "int", 5, "int", 4)
MsgBox(0, $ret, @error)

Zitat von Acanis

Beim Verkleinern ist ReDim also auf jeden Fall die bessere Wahl.
Trotzdem muss ich, da ich ja nicht das letzte Element abschneide, muss ich ja ein Hilfsarray kopieren.

In der Regel sind die nativen Funktionen und Standard-UDFs besser, solange sie genau das tun, für was du sie brauchst.
Bei der UDF wird nicht in ein Hilfsarray kopiert.
Da wird einfach ab dem zu löschenden index alles um einen verschoben und danach das array um 1 verkleinert.

Komplett sicher gibt es nicht.

Ini-Dateien sind zum lesen und verändern da, deswegen ist es recht wahrscheinlich, dass jemand sie verändert und nichts böses ahnt.

Deswegen schlage ich vor, eine normale Datei zu nehmen. Du musst einfach die Daten so abspeichern, dass du sie wieder auslesen kannst. Um heimliche Dateienveränderer abzuschrecken sind Binärdaten recht praktisch. Die Dateiendung sollte auch darauf hinweisen. Ich nehme z.B. oft .dat für die geladenen Daten und .sav für gespeichertes.

Ich werde auch dieses Jahr fertig und werde dann mit einem Informatikstudium beginnen, aber an einer Uni. Von Informatik an der FH hat mir jemand abgeraten und dieser jemand unterrichtet dort auch.

Zu anderen Sprachen:
Wer richtig Informatik machen will, sollte einen groben Einblick in viele Sprachen haben. Viele Sprachen sind zwar schwer, aber man lernt damit etwas über Computer. Bei C muss man zum Beispiel die ganze Speicherverwaltung selber machen, deswegen ist es sehr schwer. Es gibt auch nur wenige grundlegende Funktionen, den Rest muss man selber schreiben oder mit Libraries einbinden. Man programmiert halt sehr hardwarenah.
C++ ist später einfacher, weil man die Speicherverwaltung in Klassen kapselt, bzw. fertige Klassen verwendet, sodass man z.B. für strings und arrays den ganzen Kram nicht mit einzelnen Funktionen selber machen muss. Dafür wird man am Anfang von der Standartlibrary und den ganzen Features förmlich erschlagen. Deswegen verwenden leider viele Anfänger von den C++-Featuren nur wenige Klassen und sonst schreiben sie C-Code. Der Anfang ist schwer und man hat schon mit einfachsten Programmen, die mit AutoIt in kürzester Zeit geschrieben sind, große Probleme. Dennoch lohnt es sich und man braucht es auch, weil C und C++ häufig als die Standartprogrammiersprachen angesehen werden und viele OpenSource Programme in diesen Sprachen sind.

Sehr gut finde ich auch Python, auch wenn ich es noch kaum benutze. Als ich damals angefangen habe mit programmieren, hab ich gleich mit Python begonnen, die Probleme fingen aber schon mit dem Ausführen von Skripten an.

Der Anfang wird aber immer schwierig, weil diese Sprachen viel komplexere Syntax haben als AutoIt und für große Programme ausgelegt sind. Zudem vermisst man auch Funktionen, die bei AutoIt selbstverständlich sind, wie z.B die Funktion Hex

For $i=$start To $end Step $step
; ...
Next

Die Laufvariable (hier $i) startet mit dem Wert $start. Bei jedem Durchlauf der Schleife wird sie um $step erhöht, bis sie $end erreicht hat. Step ist optional (standart 1), muss also nicht jedesmal geschrieben werden.

For $i=0 To 4
MsgBox(0, "", $i)
Next

ist das gleiche, wie

MsgBox(0, "", 0)
MsgBox(0, "", 1)
MsgBox(0, "", 2)
MsgBox(0, "", 3)
MsgBox(0, "", 4)