Hi, schau mal hier rein, und mache alles so, wie es beschrieben ist. Falls alles funktioniert, schön! Falls nicht, bitte hier einen detaillierten Fehlerbericht posten!
Und erst dann an Programmen rumschreiben/verändern, wenn man auch weiss was man tut.
"..Müsste eigentlich funktionieren, ich hab ja kaum was verändert!" ist die Fehlerursache Nr.1.
ja, genau, für die gesamte "Familie"
Zitat von slashIch versuche es zu verstehen aber versteh es nicht wirklich, wenn ich denke die funktion is überflüssig und ich sie raus nehme , geht es nicht mehr
Zitat von slashAm besten wäre halt wenn sich jemand einen kurzen Moment (Jetz wo das Script eher klein gehalten ist) zeit nimmt und mir die Funktionen aufteilt und kommentiert.
Die fett gedruckten Aussagen stehen im direkten Zusammenhang. Wenn du nicht verstehst was in deinem Programm vor sich geht, wirst du nie benötigte oder nicht benötigte Funktionen ändern oder erweitern können.
Das was du hier "erbittest" kostet in der realen Welt einen Haufen Geld. "Spezialisten" wühlen sich durch anderer Leute Code und zerpflücken ihn nach Strich und Faden. Das dauert meistens länger als den Code (auch durch durch C&P) zu erstellen.
Kommentare sind immens wichtig. Erstens für denjenigen, der deinen Quellcode/deine Funktionen auch benutzen/verstehen möchte, und zweitens für dich, denn damit rufst du Erinnerungen und Verständnis für die Problemlösung ab. Vor allem, wenn beschrieben wurde, WARUM du etwas bestimmtest so gemacht hast.
Irgendwo habe ich einmal gelesen "Guter Code ist selbsterklärend". Da stimme ich teilweise zu. Die "richtige" Wahl der Namen von Funktionen und Variablen (Prä- und Postfix) hilft extrem, lesbaren Code zu produzieren. Wenn dann noch erklärt wird, warum und wieso etwas passiert, kann man Quellcode "lesen wie ein Buch".
Ich selbst habe "Programmieren" nie richtig gelernt. Learning by doing war die Devise! Daher fällt es um so schwerer, mit fortgeschrittenem Alter nicht "auf die dunkle Seite der Macht zu geraten". Ziel sollte sein, seinen Stil zu verbessern. Sagen wir mal so, ich habe mir fest vorgenommen, daran zu arbeiten 
"Form follows Function!"
Solange alles zu deiner Zufriedenheit funktioniert, würde ich nicht jemand anderen im Code rumschreiben lassen.
Natürlich sind andere Meinungen wichtig, das bezieht sich aber nicht auf den Code, sondern auf Ideen, Usability und den "Wohlfühlfaktor" der Software.
Daran haben die Spezialisten zu 100% eher etwas zu meckern, als an irgendeiner "ungewöhnlichen" Programmiertechnik...
Wenn das Programm als *.EXE vorliegt, interessiert NIEMANDEN mehr der Quellcode! Wenn das Programm fehlerhaft, schlecht bedienbar und zu langsam ist, nützt der schönste Quellcode nichts, dann gehört dein Script ins Nul-Device!
hups, mein Fehler^^
man sollte auch die Scripte durchlesen...bzw wenigstens ab und zu mal Koda benutzen 
Schreib doch, wie von Micha_he mit Eval() vorgeschlagen, nach der Koda-Sektion in deinem Script einfach einen "InputXX_nach_Array" - 5 Zeiler...
[autoit]$i=0
while isdeclared("Input"&$i)
$array[$i]=eval("Input"&$i)
$i=$i+1
wend
dann kannst du mit koda GUIs erstellen, und hast trotzdem deine arrays
Beispiel um aus einer Assemblerfunktion eine DLL zu machen
Wenn man erfolgreich eine Funktion in Assembler erstellt hat, und diese Funktion auch anderen zur Verfügung stellen möchte, bietet sich eine DLL an.
Somit kann eure Funktion auch von Leuten genutzt werden, die nicht in AutoIt programmieren....
Ich habe folgende kleine Funktion, um aus farbigen Bildern Graustufenbilder zu erstellen.
#include <AssembleIt.au3>
#include <Array.au3>
#include <GDIPlus.au3>
#include <ScreenCapture.au3>
;grau = (RR + GG + BB) / 3
func _graustufen()
_("use32") ;sollte immer eingesetzt werden!
_("mov esi,dword[esp+4]") ;Startadresse Bitmapdaten (Pixel)
_("mov ecx,dword[esp+8]") ;anzahl Pixel
_("mov edi,21845") ;konstante, *21845/2^16 ist ungefähr 1/3
_("_schleife:") ;so lange, bis ecx=0
_("mov edx,[esi]") ;pixel laden AARRGGBB (RR+GG+BB)/3 =farbe graustufe
_("mov al,dl") ;lowbyte (BB) vom Pixel nach lowbyte al
_("movzx bx,dh") ;highbyte (GG) vom Pixel nach lowbyte von bx (bh ist 0)
_("shr edx,8") ;RR ins dh schieben
_("add ax,bx") ;BB + GG
_("movzx bx,dh") ;highbyte (RR) vom Pixel nach lowbyte von bx (bh ist 0)
_("add ax,bx") ;und dazuzählen dx=RR+GG+BB
_("mul edi") ;*21845 *21845/2^16 ist ungefähr 1/3
_("shr eax,16") ;/2^16 in al steht nun der farbcode (grauton) für RR, GG und BB
_("movzx dx,al") ;grauton nach dl, in dh steht 0
_("shl edx,16") ;grauton nach RR, in AA steht 0!
_("mov dh,al") ;grauton nach GG
_("mov dl,al") ;grauton nach BB In edx steht nun 00alalal=grauton
_("mov [esi],edx") ;pixel schreiben
_("add esi,4") ;nächstes Pixel(32 Bit = 4 Byte)
_("loop _schleife") ;ecx=ecx-1 , so lange zu _schleife springen, bis ecx=0
_("ret 8") ;ACHTUNG, in der neuesten ASSEMBLEIT nur noch RET, ohne die 8 !
endfunc
_GDIPlus_Startup()
_ScreenCapture_Capture(@ScriptDir&"\testfile.jpg",0,0,@DesktopWidth,@DesktopHeight)
$hBitmap=_GDIPlus_ImageLoadFromFile(@ScriptDir&"\testfile.jpg")
Local $iWidth, $iHeight, $hBitmapData, $Scan, $Stride, $tPixelData, $pPixelStruct
$iWidth = _GDIPlus_ImageGetWidth($hBitmap)
$iHeight = _GDIPlus_ImageGetHeight($hBitmap)
;Pointer auf die Pixel ermitteln
$hBitmapData = _GDIPlus_BitmapLockBits($hBitmap, 0, 0, $iWidth, $iHeight, BitOR($GDIP_ILMREAD, $GDIP_ILMWRITE), $GDIP_PXF32RGB)
$Scan = DllStructGetData($hBitmapData, "Scan0")
$Stride = DllStructGetData($hBitmapData, "Stride")
$tPixelData = DllStructCreate("dword[" & (Abs($Stride * $iHeight)) & "]", $Scan) ;struct enthält die Bitmap (Pixel)
;farben --> grautöne
$ret=_AssembleIt("ptr","_graustufen","ptr", DllStructGetPtr($tPixelData), "int", $iWidth * $iHeight) ;
_GDIPlus_BitmapUnlockBits($hBitmap, $hBitmapData)
_GDIPlus_ImageSaveToFile($hBitmap, @ScriptDir & "\testfile_grau.jpg")
ShellExecute(@ScriptDir & "\testfile_grau.jpg")
[/autoit]
Aus dem Assemblerteil soll eine DLL erstellt werden.
Hier das Grundgerüst einer DLL, in eurem FASM-Ordner existiert eine Datei FASMW.EXE, das ist die FASM-IDE. Starten und den folgenden Code in den FASMW-Editor kopieren. Nach einem CTRL+F9 (Run;Compile) wird die DLL erstellt.
Ich werde die einzelnen Zeilen des folgenden Codes hier nicht weiter kommentieren, wer sich über die Eingeweide von DLL´s informieren möchte kann gerne die Suchmaschine seiner Wahl benutzen, oder Fragen im Assembler-Fragethread stellen!
; DLL creation example
;
;1) Funktion erstellen in der section .text
; proc Funktionsname
; AssemblerCode....wie er in AutoIt lauffähig ist... hierhinkopieren
; endp
;
;2) In die section .edata den Funktionsnamen eintragen:
;export 'DLLNAME.DLL',\ ;Name der DLL-Datei
;Funktionsname1,'Funktionsname1',\ ;Funktionsnamen
;Funktionsname2,'Funktionsname2'
;
;3) *.asm-datei mit wfasm.exe oder fasm.exe compilieren (in FASMW.EXE laden und CTRL+F9 drücken)
;
;Aufruf aus AutoIt mit
;$ret=dllcall("dllname.dll","RückgabeTYP","Funktionsname","TYP",$parameter1)
format PE GUI 4.0 DLL
entry DllEntryPoint
include 'win32ax.inc' ;includes
[/autoit] [autoit][/autoit] [autoit];einzubindende Librarys
section '.idata' import data readable writeable
library kernel,'KERNEL32.DLL',\
user,'USER32.DLL'
;************Hier die in der DLL verwendeten Funktionen für den Export eintragen
section '.edata' export data readable
export 'TESTDLL.DLL',\ ;Dateiname, Zeilentrenner ist ,\
TestFunc,'TestFunc',\ ;Funktion
AddTwoInt,'AddTwoInt',\ ;Funktion
Graustufen,'Graustufen' ;letzte Funktion ohne das ,\
;weitere Sektionen je nach Anforderung der Funktionen
section '.data' data readable writeable
_var1 dd ? ;irgendwelche Variablen, wie sie in den Funktionen verwendet werden
_var2 db ?
_sechsundsechzig = 66 ;konstante
;section für die Funktionen
section '.code' code readable executable
;DllEntryPoint wird beim Laden der DLL aufgerufen
;um "bombensicheres" Errorhandling zu haben, Funktion anpassen!
proc DllEntryPoint hinstDLL,fdwReason,lpvReserved
mov eax,TRUE ;hart aber herzlich^^
ret
endp
;******************Ab hier fangen die Benutzer-Funktionen an **********
[/autoit] [autoit][/autoit] [autoit]proc Graustufen
;ab hier folgt der Code, wie er z.B. von AssembleIt verarbeitet wird
use32
mov esi,dword[esp+4] ;Startadresse Bitmapdaten (Pixel)
mov ecx,dword[esp+8] ;anzahl Pixel
mov edi,21845 ;konstante, *21845/2^16 ist ungefähr 1/3
_schleife: ;so lange, bis ecx=0
mov edx,[esi] ;pixel laden AARRGGBB (RR+GG+BB)/3 =farbe graustufe
mov al,dl ;lowbyte (BB) vom Pixel nach lowbyte al
movzx bx,dh ;highbyte (GG) vom Pixel nach lowbyte von bx (bh ist 0)
shr edx,8 ;RR ins dh schieben
add ax,bx ;BB + GG
movzx bx,dh ;highbyte (RR) vom Pixel nach lowbyte von bx (bh ist 0)
add ax,bx ;und dazuzählen dx=RR+GG+BB
mul edi ;*21845 *21845/2^16 ist ungefähr 1/3
shr eax,16 ;/2^16 in al steht nun der farbcode (grauton) für RR, GG und BB
movzx dx,al ;grauton nach dl, in dh steht 0
shl edx,16 ;grauton nach RR, in AA steht 0!
mov dh,al ;grauton nach GG
mov dl,al ;grauton nach BB In edx steht nun 00alalal=grauton
mov [esi],edx ;pixel schreiben
add esi,4 ;ein Pixel = 32Bit = 4Byte weiter
loop _schleife ;ecx=ecx-1 , springe so lange nach _schleife, bis ecx=0
ret 8
endp
;eine weitere Funktion gibt die eingegebene Zahl einfach zurück
proc TestFunc Zahl:DWORD
mov eax,dword[Zahl]
leave ;nötig, wenn ebp nicht verwendet wird (pop ebp to esp)
retn 4
endp
;und noch eine Funktion addiert zwei Integer....
proc AddTwoInt Zahl1:DWORD ,Zahl2:DWORD
mov eax,dword[Zahl1]
mov ebx,dword[Zahl2]
add eax,ebx
leave
retn 8
endp
section '.reloc' fixups data discardable
[/autoit]Im Prinzip besteht die "Arbeit", einen Funktionsnamen zu erstellen und den Assemblercode zwischen proc/endp zu kopieren, und den Funktionsnamen in die Section .edata einzutragen.
/EDIT/ Das gilt natürlich nur für relativ "einfache" Funktionen. Wer mit AutoIt-DllCallbacks() und weiteren Spezialitäten in seinem Assemblercode arbeitet, muß sich Gedanken machen, wie diese Adressen in die Dll-Funktionen kommen.
Die größte "Arbeit" ist, die _(" und die ") um die eigentlichen Assemblerbefehle herum zu löschen^^, aber wozu gibt es AutoIt, damit kann man sich ein Script erstellen, so daß auf Knopfdruck der "bereinigte" Code in der Zwischenablage steht und nur noch per CTRL+V eingefügt werden muss...
Nachdem die DLL erstellt wurde, kann man nun aus AutoIt folgendermassen die Funktionen in der DLL aufrufen:
#include <GDIPlus.au3>
#include <ScreenCapture.au3>
$testdll=dllopen("testdll.dll")
[/autoit] [autoit][/autoit] [autoit]_GDIPlus_Startup()
_ScreenCapture_Capture(@ScriptDir&"\testfile.jpg",0,0,@DesktopWidth,@DesktopHeight)
$hBitmap=_GDIPlus_ImageLoadFromFile(@ScriptDir&"\testfile.jpg")
Local $iWidth, $iHeight, $hBitmapData, $Scan, $Stride, $tPixelData, $pPixelStruct
$iWidth = _GDIPlus_ImageGetWidth($hBitmap)
$iHeight = _GDIPlus_ImageGetHeight($hBitmap)
$hBitmapData = _GDIPlus_BitmapLockBits($hBitmap, 0, 0, $iWidth, $iHeight, BitOR($GDIP_ILMREAD, $GDIP_ILMWRITE), $GDIP_PXF32RGB)
$Scan = DllStructGetData($hBitmapData, "Scan0")
$Stride = DllStructGetData($hBitmapData, "Stride")
$tPixelData = DllStructCreate("dword[" & (Abs($Stride * $iHeight)) & "]", $Scan)
;DLL-Call für die Graustufenfunktion
$ret= DllCall("testdll.dll", "ptr", "Graustufen","ptr", DllStructGetPtr($tPixelData), "int", $iWidth * $iHeight)
;Dll-Call für die AddTwoInt()Funktion
$ret= DllCall("testdll.dll", "int", "AddTwoInt","int", 33333, "int", 44444);bytecode aufrufen, rückgabe in a[0]
Consolewrite("AddTwoInt() = "&$ret[0]&@crlf)
_GDIPlus_BitmapUnlockBits($hBitmap, $hBitmapData)
_GDIPlus_ImageSaveToFile($hBitmap, @ScriptDir & "\testfile_grau.jpg")
ShellExecute(@ScriptDir & "\testfile_grau.jpg")
[/autoit]
Und die Dll, wie sie von FASM erstellt wurde...
/EDIT/ Wenn man die Dll disassembliert wird man sehen, daß FASM "eigenständig" den Base- und Stackpointer rettet und auch dementsprechend die richtigen Rücksprungadressen ermittelt. Auf die hier gezeigte Art und Weise (per in AutoIt eingebettetem FASM) wird man keine "großen" Dll's erstellen, dafür sind dann "richtige" Assembler (FASM, FASMW) wesentlich besser geeignet! Dort hat man mit den Bibliotheken vollen und sehr einfachen Zugriff auf u.a. die WinAPI-Funktionen, Macros und vieles mehr.
Bei den von mir getesteten Windowsversionen (XP,Vista,Win7 alles 32Bit) hat es auch nichts ausgemacht, die alphabetische Reihenfolge der Funktionsnamen in der Dll durcheinanderzuwürfeln.
Der HWND-Parameter bei Inputbox() ist dafür zuständig
$hgui=guicreate("")
WinSetOnTop($hgui, "", 1)
guisetstate()
$answer = InputBox("Question", "Where were you born?", "Planet Earth", "", -1, -1, default,default,default, $hgui)
[/autoit] [autoit][/autoit] [autoit][/autoit]Aber eine Frage: Anscheinend braucht xor ja weniger Byte, benötigt aber dieselbe Anzahl an Parameter wie mov, warum ist xor kürzer?
Das ist "hardcodiert"... Im Prinzip kannst du mit 2-Byte-Opcodes um die 255x255 Befehle "darstellen". So viele gibt es aber garnicht, also gehen die Prozessorhersteller hin, und "konstruieren" oft benutzte Befehle in 2- oder 3-Byte Opcodes.
So kommt es auch vor, dass einige unterschiedliche Befehle identische Opcodes haben.
Da es etwas übel wäre, die Opcodes für 65000 Befehle in eine Liste zu schreiben, werden die Opcodes Bitweise nach bestimmten Regeln ermittelt. Das ist schweres Futter, das richtige für Nerds zum austoben^^
U.a in den Intel-Handbüchern findest du seitenlange Erklärungen und Tabellen, wie sich Opcodes zusammensetzen. Aber "brauchen" tut das kein Mensch, obwohl ich mal einen kannte, der diese "Regeln" grösstenteils auswendig konnte. Damit ist man z.B. in der Lage, ohne Compiler/Assembler Programme zu schreiben^^...wers braucht...
Aber jemand, der einen Assembler/Compiler erstellen möchte, sollte sich mit diesem Thema auskennen....
Naja wenn man sich den Assembler Code einer exe Anwendung anschaut,
Falsch, den disassemblierten Code einer Anwendung! Und genau das ist das Problem! Die "gängigen" Compiler verwenden natürlich den XOR, weil der Opcode 4 Byte kürzer ist, damit hat es sich schon. Wenn du einem Assembler sagst, er soll ein MOV kodieren, dann macht der das auch in der Regel! Assembler optimieren nicht, Compiler schon.....
Hi,
warum verwendest du doppelt genaue Flieskommazahlen für eine Kollisionsabfrage? Die werden Prozessorintern mit 80 Bit Genauigkeit gerechnet, je nach aktuellem Luftdruck bzw Schönwetterlage bekommst du 18 Nachkommastellen. Muß das dermassen genau sein?
Integer ist 10-20x schneller und auch einfacher programmiert^^! Der Compiler kann nichts für die Stalls, so wie ich den Code verstanden habe sind das eine Handvoll Additionen und Vergleiche. Machs in Integer und teste mal, ob AutoIt nicht schneller ist, das ist kein Witz!
Ausserdem wäre ein Besuch im örtlichen Kindergarten angebracht, lass dir dort beibringen, wie man bis 8 zählt.....
$a= _Collision(0, 0, 20, 20, 50, 50, 20, 20)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $a= = ' & $a & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
Func _Collision($ObjectX, $ObjectY, $ObjectWidth, $ObjectHeight, $WallX, $WallY, $WallWidth, $WallHeight)
Local $DllOpen = DllOpen("Collision.dll")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $DllOpen = ' & $DllOpen & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
Local $Call = DllCall($DllOpen, "double", "Collision", "double", $ObjectX, "double", $ObjectY, "double", $ObjectWidth, "double", $ObjectHeight, "double", $WallX, "double", $WallY, "double", $WallWidth, "double", $WallHeight)
If IsArray($Call) Then
Return $Call[0]
Else
Return -1
EndIf
EndFunc ;==>_Collision
ich will eigentlich auch nur jemanden haben der mir erklärt wie das mit Select funktioniert
Wenn du Informationen zu Select suchst, wieso stellst du keine Frage die uns zeigt, dass du dich mit dem Befehl bereits beschäftigt hast aber etwas bestimmtes nicht verstehst?
Und Frage 2 ist halt nur so, weil ich das schon immer mal wissen wollte
Ich wollte auch schon immer mal wissen, warum mir niemand sofort Bescheid sagt, wenn in China mal wieder ein Sack Reis umfällt.
Falls es hier im Board andere nette User gibt, ich kann Hilfe gebrauchen.
Das merkt man allerdings deutlich!
Damit dir jemand hilft, solltest du dir angewöhnen Fragen richtig zu stellen. Das erhebt dich innerhalb eines kurzen Augenblicks zu einem interessanten und interessierten Hilfesuchenden. Wenn du das nicht willst, lerne mit den bisher gegebenen Antworten zu leben, mehr wirst du selten bekommen.....
Andy, das ist Intuition
GEIL! Vielen Dank!
Hab direkt noch eine Flasche "Intuition" von Estée Lauder bestellt....Meine Frau sprüht sich das zwar unter die Ohren, aber wenn du sagst, es erweitert das Bewusstsein, dann nehm ich gleich mal nen ordentlichen Schluck davon.......Bääääääähhh, von wegen blumig.....das nächste Mal bleib ich bei meiner Kugel!
Hi,
du wirst es nicht glauben, GENAU dasselbe Problem habe ich auch!
Aber als ich das Problem genau so wie Du hier beschrieben hatte, wollte irgendein Idiot doch tatsächlich meinen wertvollen Code sehen, als ob diese Pfeife sich die Lösung nicht so aus den Fingern saugen konnte. Wahrscheinlich war das ein NOOB, der absolut KEINE Ahnung vom Programmieren hat!
Was soll so einer auch mit Quellcode anfangen! Als ob der den Mist, den ich da verzapft hab und nun selbst nicht mehr durchblicke, kapieren würde!
Jedenfalls warte ich immer noch auf Antwort....
Wenn du den passenden Hinweis bekommst oder dir jemand sogar ein komplettes Programm schreibt, sag bitte Bescheid....sonst macht mein Programm ja ewig genau das, was ich da wollte....
Debugger jedoch machen immer xor
Macht das der Debugger (weils angeblich "professioneller" aussieht) oder steht das im Code?
Der Compiler macht aus dem XOR ein MOV (weils eh keiner merkt), macht aber nix, weil der Debugger ja aus dem (noobigen) B800000000 ein 31C0 macht und so ganze 4 Bytes "spart"....
*whispermode ON*
Die 4 "eingesparten" Bytes des XOR machen dann Sinn, wenn man anfängt, in den Eingeweiden des Prozessors zu optimieren oder wenn man aus welchen Gründen auch immer 4 Bytes im Code einsparen MUSS. Für die 08/15 Anwendung hat mir noch keiner nachweisen können, daß ein MOV statt des XOR den Code zum Schneckentempo verurteilt....
*whispermode OFF*
Was mich an den Witz erinnert vom kleinen Jungen, der mit seinem Dreirad gemütlich vor der Strassenbahn herfährt. Der Strassenbahnfahrer klingelt wie wild, irgendwann reichts ihm und er brüllt aus dem Fenster:" Hey, Kleiner! Kannst du nicht ein bisschen schneller fahren?" Darauf dreht sich der Junge um, grinst den Strassenbahnfahrer an und sagt: "Ich schon.....aber du nicht!" 
Raupi, jetzt REICHTS!
Sofort verrätst du mir, welche bewusstseinserweiternden Drogen du nimmst, um ZU AHNEN, welche Funktion der TE haben wollte, ohne einen einzigen (sinnvollen) Hinweis zu geben!
Oder hast du etwa schon die "Glaskugel 2.3", die lt. Werbung ja (unbestätigt) in der Lage sein soll, SICH SELBST ZU POLIEREN! Ich hab immer noch die Version 2.2 und muss mir hier jeden Abend die Finger wund wischen...Wahrscheinlich muss die Kugel auch deswegen so oft zur Reparatur, man sollte ggf. mal über Inrechnungstellen von passenden Antworten nachdenken!
Hi,
die "UDF" ist ein vollwertiger Assembler, ich habe bis jetzt keinen (wichtigen) Befehl vermisst. Daß irgendwelche prozessorspezifischen Spezialitäten (u.a aus SSE4.0) erst vor kurzem implementiert wurden ist nicht erwähnenswert.
Geht es nicht schneller wenn man das Register mit sich selber Xor'd? Oder gibts XOR nicht bei der UDF irgendwie?
Ob ein XOR schneller ist? Kommt auf den Code insgesamt an! Sagen könnten das ggf. Analysten und vielleicht eine Handvoll guter Compilerbauer. Da moderne Prozessoren ihre Befehls-Pipelines selbstständig verwalten/umsortieren, Sprungvorhersagen nach bestimmten Algorithmen "schätzen" und selbstständig versuchen Abhängigkeiten aufzulösen hängt die Geschwindigkeit nicht an einem Befehl, sondern an einer kompletten Befehlskette.
Will sagen, wenn du in einem Loop permanente Stalls hast, ist es sch***egal, ob das XOR einen halben oder einen viertel-"Takt" schneller ist als ein MOV. Wenn der Prozessor hunderte von Wartetakten einfügen muss weil der Programmierer "gegen" den Prozessor arbeitet, ist der schnellste Befehl für die Katz...
Mach doch einfach mal eine "laaaange" Schleife und probiers aus. Aber ups, je länger die Schleife desto eher schlägt das Betriebssystem zu und interrruptet fleissig...
Viel Spass beim Programmieren eines Timers, der "Takte" zählen kann. Diese Timer bzw. Programme gibt es, die machen aber m.E. nur dort Sinn, wo es wirklich um GELD geht, also um Berechnungen auf extrem teuren Maschinen. Ruf mal beim CERN an (ich habe das mal spasseshalber vor einigen Jahren gemacht, weil einer meiner ehemaligen Profs wieder dort arbeitet) und frag mal nach, was eine Stunde auf einer 200-Prozessor-Maschine mit 5 Terabyte RAM kostet....
Für den "Otto-Normal-Programmierer" ist der Unterschied definitiv nicht feststellbar (beim Tippen dieses Textes "schläft" mein Prozessor mehr als das er arbeitet). Ich schliesse mich aber der Meinung eines Softwareentwicklers/Testers an, der mir einmal sagte:" Ein MOV EAX,0 ist für jeden ohne Nachdenken (auch unbewußt) nachvollziehbar und stört nicht den "Fluß" beim Lesen des Codes. Selbst wenn ein XOR EAX,EAX schneller WÄRE (was es zu beweisen gilt) ist dem MOV dennoch der Vorzug zu geben!"
Mit dem Compiler von AutoIt sind die Programme immer ziemlich langsam, wenn man das nach C++ übertragen würde wäre es sicherlich um einiges schneller, oder nicht?
Das "langsame" hängt daran, dass AutoIt garkein Compiler ist, sondern ein Interpreter. Und "immer ziemlich langsam" ist gelogen, etliche Funktionen sind wie schon von mir beschrieben nur "Wrapper" für WinApi-Calls.
Andy, weil man in C++ aus FileRead() so ... 5 - 10 Zeilen machen muss
Das war nur ein Bsp
Ja wie jetzt, gehts um "einfacher" oder "schneller" oder "kürzer"?
Wer hindert dich denn in C++ eine Funktion _FileRead(para,para2,para3,para....) zu schreiben, die das C++-Gewurstel in einer Zeile abhandelt?
Freunde der Nacht, mal ganz ehrlich, C++ ist deswegen bei "richtigen" Programmierern so beliebt, weil es für so gut wie jeden kleinen Sch*** eine passende Funktion gibt. Der Skill eines guten Programmierers ist nicht, am Tag 800 Zeilen bugfreien Code in die Tastatur zu kloppen, sondern die 10 Funktionen aus den Bibliotheken zusammenzusuchen, die sein Problem zu 99,8% erledigen und die restlichen 5 Zeilen Code dazuzuschreiben.
Der eigentliche C++ Compiler wird nur noch als "Zusammenbaumaschine" benutzt....denkt mal drüber nach, wenn ihr in AutoIt das nächste Mal eine bestimmte Funktion (UDF) bräuchtet....zu 99% gibts die bereits....
Wieso Funktion? Da gibts ganze Programmgruppen die nichts anderes machen.
Hexeditoren (z.B. HxD) oder Debugger/Disassembler (z.B. Ida Pro Free) oder lade die EXE-Datei einfach in Scite und such dort nach Strings mit Ctrl+F....
