ObjT

Hier ist noch ein weiterer Tipp, wenn du im 1. Thread eine Changelog führst mit was für Sachen in welchen Versionen dazugekommen sind dann wird dir niemand deswegen böse werden.
Und noch was: Wenn du in C++ die grundlegenden Sachen der Console kannst dann kannst du die Zwischeninstanz AutoIt vergessen und gleich in C++ vom Interpreter konvertieren lassen.

Ich schreib das ganze was ich per PN an Robin98 gesendet hab mal hier rein, damit auch andere einen Blick drauf werfen können!

Zitat

Du meinst ja in deiner Sprache das man oben Die Zeilen + 2 oder so schreiben soll.
Wieso machst du das nicht so, das wenn du wirklich die Zeilen vom Script brauchst die Anzahle der @CRLFs zählst.
Ein @CRLF ist nichts mehr als ein Zeilenumbruch.

[autoit]

;--------------------------------------------------------
$sString = "Hallo1234"
$sString = StringReplace($sString, "H", "h")
$sString = StringReplace($sString, "a", "A")
;--------------------------------------------------------

[/autoit] [autoit][/autoit] [autoit]

#cs
Zwischen den ;---- befinden sich 3 Zeilen.
Hinter dem "Hallo1234" ist ein Zeilenumbruch oder auch @CRLF (Carriage Return Line Feed) genannt.
Hinter dem ,"h") ist ein @CRLF
und hinter dem , "A") ist ein @CRLF.

[/autoit] [autoit][/autoit] [autoit]

Somit siehst du das das Script 3 Zeilen hat. Wenn es z.B. so ist:
#ce

[/autoit] [autoit][/autoit] [autoit]

;--------------------------------------------------------
$sString = "Hallo1234"
$sString = StringReplace($sString, "H", "h")
$sString = StringReplace($sString, "a", "A")

[/autoit] [autoit][/autoit] [autoit]

;--------------------------------------------------------

[/autoit] [autoit][/autoit] [autoit]

#cs
Dann siehst du, das da 4 Zeilen sind, und wenn dir das nicht passt schaust du ob in dieser Zeile was ist.
Wie macht man das? Du schneidest alles was sich links von dem letzen @CRLF befindet weg (so das nur die letzte Zeile bleibt) oder guckst mit _StringBetween ob zwischen zwei @CRLFs was stehen und löscht die Zeile.
Ich weiß nicht ob das in deinem Interpreter drinne ist aber du könntest überprüfen, wenn ein do{ drinne ist, ob dann ein do} drinne ist.
#ce

[/autoit]

Bei deinem Interpreter ist noch SEHR viel zu machen, Syntaxfehlererkennung etc...
Viel Spaß und viel Erfolg von mir!

Alles anzeigen

Zitat von Xorianator

Gerade weil du eine Hochsprache wie AutoIt wieder downgradest

Facepalm

Zitat von Darter

Facepalm

Aha, weshalb? Recht hat er.

Zitat

Syntax oft an menschliche Denkgewohnheiten angepasst, Größtenteils maschinenunabhängig, Mehrere Kontrollstrukturen (if, while,...), Geschwindigkeitsverlust durch Abstraktion (tendenziell), Weitgehende semantische Analyse möglich

http://de.wikipedia.org/wiki/Höhere_Programmiersprache#Vergleich_zur_Assemblersprache

Freut mich das ich helfen kann!

Hey!
Genau genommen arbeitest du da an einem Konverter und keinen Interpreter...
Wenn du dass noch nicht mit der Maschinensprache hinbekommst, versuch doch einfach mal deine Syntax tatsächlich zu interpretieren und nicht zu konvertieren.

Falls dir der Unterschied nicht klar ist:
Ein Konverter konvertiert eine Datei in eine andere. Bei dir ist dies von ObjT nach AutoIt.
Ein Interpreter interpretiert die Datei zur Laufzeit und führt die Befehle des Codes aus.

Beispiel:
var xyz = 12 // Erstellt eine Variable
out xyz // Gibt die Variable aus

Dein Konverter würde nun (wenn er die Syntax so erkennen würde) folgendes machen:
Suche Schlüsselwörter wie "var" oder "out" und konvertiere sie in AutoIt Befehle.
Danach suche Variablen und setze ein $ Zeichen davor.
Zuletzt ändere die Zeichen die auf ein Kommentar hindeuten in ein Semikolon um.

Global $xyz = 12 ; Erstellt eine Variable
ConsoleWrite($xyz) ; Gibt die Variable aus

Ein Interpreter würde folgendermaßen arbeiten:
Gehe den Code Zeile für Zeile durch und suche nach Schlüsselwörtern, Funktionen etc...
Zeile 1: var xyz = 12 // Erstellt eine Variable
>> var als Schlüsselwort erkannt >> xyz ist demnach der Variablenname >> 12 der zugewiesene Wert
>> Speicher die Variable in dem vorgesehenen Array für die Variablennamen + Werte ab >> $avVariablen[0][0] = 'xyz' >> $avVariablen[0][1] = '12'
>> Kommentar wird ignoriert | Nächste Zeile
Zeile 2: out xyz // Gibt die Variable aus
>> out als Schlüsselwort erkannt >> xyz weder String noch ein Ausdruck, es wird in der Variablenliste geschaut ob dies ggf. Eine Variable sein könnte
>> $avVariablen wird durchgegangen und xyz wurde in $avVariablen[0][0] gefunden. Der Wert steht in $avVariablen[0][1] und ist demnach 12.
>> 12 wird ausgegeben.
>> Kommentar wird ignoriert | Nächste Zeile
Code Ende wurde erreicht

Ich hoffe du siehst wie ich das meine...
Versuch dich direkt an den Interpreter anstatt dem Konverter...
Dann kannst du auch tatsächlich eine unabhängige Skriptsprache mit eigenen Funktionen etc. entwickeln.

Ich schreibe gerade auch (wegen dem Thread hier) einen kleinen Interpreter der als Beispiel dienen soll.
Oder suche mal nach "AutoFuck". minx hat da auch einen kleinen Interpreter gebastelt wenn ich mich richtig erinnere.

LG. Make

Genau so hatte ich das auch gemeint.
Schön, dass du das so ausführlich erklärt hast.

MfG James

Zitat von Make-Grafik

[...]suche mal nach "AutoFuck"[...]

Da kommen bei google interessante Sachen 0.0

Stimmt, AutoFuck ist interessant.

lg

Selbst wenn es nur ein Konverter ist, ich finde die Grundidee sehr gut. Die Umsetzung muss stimmen und dann wird das großartig.
Bei einem Konverter von ObjT2C++ würden sich vielleicht andere Leute freuen, da sie den Unterschied vergleichen können (der Konverter kann auch in AutoIt geschrieben sein).

Der Code würde dann schnell, wirklich sehr schnell laufen. Selbst wenn es nur die minimale von C++ ist, die Konsolenbefehle sind sowas von ausreichend.
Während mein PC knapp ~25000 Primzahlen (Spektrum 2-unendlich) berechnen kann, schafft AutoIt grade einmal 1000.

alpines:
Welchen Sinn hat der Konverter?
Er ändert doch nur die Syntax von C++ (oder in diesen Fall von AutoIt).
Da kann man lieber gleich die Syntax der entsprechenden Sprache lernen und in dieser programmieren.
Zudem bin ich sicher, dass der Programmierer dann auch effizienteren Code schreiben kann als wie der Konverter das hinkriegen würde...

Aber der Threadsteller sollte wissen was er möchte...
Ich sehe keinen Sinn in den Konverter!

Zitat von Make-Grafik

Ich sehe keinen Sinn in den Konverter!

Ein weiterer für einen Interpreter sprechenden Punkt wäre, dass ein solcher schwieriger zu programmieren ist als ein Konverter (besonders verglichen mit dem Konverter in diesem Fall). Der Programmierer hätte also eine Herausforderung und würde dabei etwas lernen.

@Make-Grafik, wenn sich jemand mit dem Syntax von C++ nicht anfreunden kann, dann steht ihm eine Alternative zu.
Zugegeben das ist zwar ein bisschen unnötig aber trotzdem.

Jetzt zieht mal nicht so über Konverter her.

Was passiert denn beim Kompilieren (-> Übersetzen) eines C-Source-Files? Richtig, er wird in Assembler übersetzt und dann wird dieser ASM-Code in Maschinencode übersetzt. C wird zu ASM konvertiert, ASM wird zu Maschinencode konvertiert.

lg

Das worüber Make sich beschwert ist vermutlich das der Konverter, konvertiert aber nicht kompiliert.
Wenn der Konverter in die Sprache übersetzen würde und kompilieren würde dann ist Make zufrieden.

Zitat

Allerdings müsst ihr alle eins bedenken ich bin 14 jahre alt und soll jetzt Assembler lernen oder was?

Schlechte Ausrede! Ich bin 15

Ich meine nur, dass es Sinn macht sich an einen Intepreter zu setzen als an dem Dingen da weiter zu schreiben was du gerade machst. Siehe dazu auch Post #32.

Soweit ich weiß ist doch Assembler prozesserabhängig und ist auf jeder CPU verschieden?
Desweiteren würde ein ObjT2Assembler Interpreter nur auf einem emulierten Mikroprozessor in Windows funktionieren ansonsten muss man das auf einer Diskette haben und die booten.

Zitat von alpines

ein ObjT2Assembler Interpreter

Wieso benutzen die Leute immer Wörter die sie eindeutig nicht verstehen?