Hi,
ich habe mir mal einige der Codedateien angeschaut, und gehe davon aus, dass du an einen Konverter nicht mal ansatzweise wirst denken können...
Eine händische Konvertierung ist sehr mühsam
...entweder du machst das trotzdem, oder, ein Ansatz den ich ins Auge fassen würde, du kompilierst die C++-Files in eine DLL, deren Funktionen du dann per AutoIt in (nativer) Geschwindigkeit per DllCall() auch ausführen kannst.
Wobei es dann Sinn macht, alle Sourcefiles in EINE C++-Datei zu kopieren (per AutoItscript ist das nicht das Problem) und daraus dann eine DLL zu kompilieren.
Gerade bei der Geometrieverarbeitung erwartet dich in AutoIt nur Trauer und Schmerz. Ich habe selbst einiges aus C++ nach AutoIt übersetzt um einfache Tools zu basteln, und man merkt immer und immer wieder wie Pointer und Datenstrukturen fehlen.
Das ist auch das allergrößte Hindernis an einem Übersetzungsprogramm: Datenstrukturen. (das 2t größte Hindernis sind die 10.000 Stunden Aufwand die ein Übersetzer kostet)
Ja, wir haben DllStruct in AutoIt, die können aber nur primitive Datentypen halten. Möchte man verschachtelte Datenstrukturen verwenden muss man das mit Pointern erledigen. Um Pointer effektiv nutzen zu können muss man via DllstructCreate und kernel32-alloc manuell dafür sorgen, dass die Datenstruktur nicht gelöscht wird sobald keine AutoIt-Variable mehr vorhanden ist die sie hält (man will ja nur den Pointer haben), zusätzlich muss man aber irgendwie trotzdem dafür sorgen, dass der Speicher später freigegeben wird (ist möglich, aber unschön). Möchte man Datenstrukturen "in place" verwenden (z.B. Ball = (float x, float x, float diameter), BallPark = (Ball[10])) um z.B. direkt über alle "Ball" zu loopen muss man im Prinzip rekursives unrolling und alignment betreiben (sodass in der endgültigen Struct nur noch primitive vorhanden sind, die man dann auf umständliche Art und Weise via in Place erzeugter Struct anspricht). usw usw. Da kann man sich auch gleich nen eigenen Speichermanager schreiben. Was wahrscheinlich sowieso mal bitter nötig wäre, wenn man jemals über die "Struct die Primitive enthält" hinauskommen möchte.
Außerdem sind DllStructs in AutoIt deutlich langsamer als z.B. Arrays (oder seit einiger Zeit Maps mit IntegerKeys... die aus "Gründen" schneller sind als Arrays, solange die Größe < 256 Elemente ist). Was in C++ ein immenser Geschwindigkeitsvorteil ist (z.B. loop über alle "Ball", wenn sie aligned im Speicher liegen) ist in AutoIt unfassbar langsam (loop in verschachtelten Arrays/Maps). Apropos verschachtelte Arrays/Maps: Es gibt in AutoIt KEIN same scope ByRef. Du kannst den Inhalt eines Verschachtelten Arrays nicht direkt ansprechen. In der Klammersyntax ($A[0])[0] kann ein Array das in $A[0] liegt nur gelesen, aber nicht geschrieben werden, außerdem wird jedes Mal dereferenziert, wenn man das macht -> Langsam. Einziger Umweg ist über Funktionen mit ByRef Parameter, dann hat man aber den Overhead eines Funktionsaufrufs, was sich nur lohnt, wenn das Array das man beschreiben will eine gewisse Größe hat, für kleine Arrays ist 2x Kopieren schneller als 1x Funktionsaufruf mit ByRef.
Was ich damit eigentlich sagen will: Code der in C++ richtig schnell läuft muss komplett umstrukturiert werden um in AutoIt ebenfalls schnell zu laufen.
Es ist schon echt nervtötend "einfache" Sachen aus C++ von Hand zu übersetzen (ich meine nicht platten C-Code (flat API), der geht natürlich easy), und ich bin nicht in der Lage mir ein automatisches Programm dafür auch nur vorstellen zu können...
Edit: Hier mal ein Beispiel das wirklich nur für diesen einen Spezialfall funktioniert:
- Zeigt wie man "in place" eine Liste aus Structs in einer Struct bastelt, die auch (nur in diesem Fall hier) korrekt im Speicher liegt und daher von C++ 1:1 übernommen werden könnte (falls man 32bit aligned ist. bei 128 wird die Ball Struct noch 32Bit padding am Ende bekommen. Wenn man Vektorisierung angeschaltet hat wird das wahrscheinlich so sein, dann kann der Compiler auch automatisch sse verwenden, dann mag er 4x32er Blöcke lieber).
- mit "Spezialfall" meine ich z.B.: Der Typ "BALL" und der Feldname "ball" muss im UpperCase-Fall identisch sein. Man kann nicht mehrere Felder mit "BALL" Typ haben. "BALL" darf keine Feldnamen wie x, y, d haben. Und unendlich + 2 weitere Einschränkungen. Das ist kein Code den ich für irgendwas sinnvolles verwenden würde, er dient nur als Minimalbeispiel.
- Wenn man das "allgemein" Lösen will ist man Monate dran (und nicht die 15 Minuten die mich dieses Beispiel gekostet hat) und hat danach immernoch unendlich viele Bugs.
#include <Array.au3>
#include <Memory.au3>
Global $_DN[] ; Structnamen hinterlegen
Global $_DS[] ; Sizes
DllStructRegister('BALL;float;float;float')
; numBalls ist nur hier damit man zeigen kann wie man "in diesem Fall hier" das Offset berechnen kann. numBalls wird nicht verwendet.
$balls = DllStructCreate2('int numBalls;BALL ball[10]')
$oneBall = DllStructCreate2('Ball')
DllStructSetData($oneBall, 1, 1)
DllStructSetData($oneBall, 2, 2)
DllStructSetData($oneBall, 3, 3)
For $i = 0 To 9 Step 1
DllStructSetData($oneBall, 1, Random(0, 10, 1))
DllStructSetData($oneBall, 2, Random(0, 10, 1))
DllStructSetData($oneBall, 3, 7)
DllStructSetData2($balls, 'ball', $i, $oneBall) ; memcpy
Next
For $i = 0 To 9 Step 1
$v = DllStructGetData2($balls, 'ball', $i) ; $v ist jetzt die "Ball" Struct (Kopie)
ConsoleWrite('Type: ' & VarGetType($v) & ' size: ' & DllStructGetSize($v) & ' -> ')
ConsoleWrite('Ball[' & $i & ']: ' & DllStructGetData($v, 1) & ', ' & DllStructGetData($v, 2) & ', ' & DllStructGetData($v, 3) & @CRLF)
Next
Func DllStructSetData2($v, $sName, $i, $xValue)
If MapExists($_DS, StringUpper($sName)) Then
Local $size = $_DS[StringUpper($sName)]
Local $sStruct = $_DN[StringUpper($sName)]
Local $iOffset = DllStructGetPtr($v, $sName) - DllStructGetPtr($v)
Return _MemMoveMemory(DllStructGetPtr($xValue), DllStructGetPtr($v) + $iOffset + $size * $i, DllStructGetSize($xValue))
EndIf
DllStructSetData($v, $sName, $xValue, $i)
EndFunc
Func DllStructGetData2($v, $sName, $i)
If MapExists($_DS, StringUpper($sName)) Then
Local $size = $_DS[StringUpper($sName)]
Local $sStruct = $_DN[StringUpper($sName)]
Local $iOffset = DllStructGetPtr($v, $sName) - DllStructGetPtr($v)
Return DllStructCreate($sStruct, DllStructGetPtr($v) + $iOffset + $size * $i)
EndIf
Return DllStructGetData($v, $sName, $i)
EndFunc
Func DllStructCreate2($sStruct)
Local $a = StringSplit($sStruct, ';', 2), $b, $s = '', $c, $d
For $i = 0 To UBound($a) - 1 Step 1
If StringInStr($a[$i], '[', 0, 1) Then
$b = StringSplit($a[$i], '[', 2) ; TYPE name
$c = StringSplit($b[0], ' ', 2)
If MapExists($_DN, StringUpper($c[0])) Then
$d = StringSplit($_DN[StringUpper($c[0])], ';', 2)
$s &= $d[0] & ' ' & $c[1] & ';'
For $j = 1 To UBound($d) - 1 Step 1
$s &= $d[$j] & ';'
Next
For $j = 0 To Number(StringTrimRight($b[1], 1)) - 2 Step 1
$s &= $_DN[StringUpper($c[0])] & ';'
Next
Else
$s &= $a[$i] & ';'
EndIf
Else
If MapExists($_DN, StringUpper($a[$i])) Then
$s &= $_DN[StringUpper($a[$i])] & ';'
Else
$s &= $a[$i] & ';'
EndIf
EndIf
Next
ConsoleWrite($s & @CRLF)
$s = StringTrimRight($s, 1) ; remove ';'
Return DllStructCreate($s)
EndFunc
Func DllStructRegister($sStruct)
Local $sName = StringSplit($sStruct, ';', 2)[0]
$sStruct = StringTrimLeft($sStruct, StringLen($sName) + 1)
$_DN[StringUpper($sName)] = $sStruct ; String Key
Local $_ = DllStructCreate($sStruct)
$_DS[StringUpper($sName)] = DllStructGetSize($_)
EndFunclg
M
Gerade bei der Geometrieverarbeitung erwartet dich in AutoIt nur Trauer und Schmerz.
Das ist auch das allergrößte Hindernis an einem Übersetzungsprogramm: Datenstrukturen.
hmmm, sehe ich nicht so. Datenstrukturen kannst du, wie in deinem Beispiel gezeigt, "irgendwie" immer hinbiegen.....ist genaugenommen ja nur Bytes im Speicher 
Wie du auch geschrieben hattest, ist die Übersetzung von (flat) C recht einfach. Bin zwar nicht der Guru, habe mich aber in den letzten beiden Jahren intensiv mit OpenCL (natürlich aus AutoIt heraus^^) beschäftigt, und die Kernel dort sind simples C. Was für mich persönlich wirklich schön ist, denn ich kann mit einem Basic-Interpreter höchstperformanten Code schreiben, der automatisch mit der Anzahl der Cores auf CPU und GPU skaliert und sich Geschwindigkeitsmäßig hinter keiner anderen Programmiersprache verstecken muss. Von "lesbarem" Code ganz abgesehen, denn was in AutoIt "selbstverständlich" in einigen Zeilen abgehandelt wird, füllt bspw. in C++ etliche Seiten.
C++ ist dagegen die Evolutionsstufe von C nach 50 Jahren sog. "Weiterentwicklung" mehrerer zehntausend Programmierer. Da bleibt aus Sicht von AutoIt auch nicht mehr viel zu verstehen. Ich bin auch überzeugt dass 90% aller (guten) C++ - Programmierer nicht verstehen wie C++ intern abläuft. müssen die auch gar nicht, die müssen lediglich das System NUTZEN! Und da ist der "Vorsprung" von C++ uneinholbar gewaltig. Nicht etwa weil C++ so unglaublich toll ist, sondern weil es zwölfundneunzig Millionen Varianten gibt, aus 5 unterschiedlichsten Zeilen Quellcode identisch compilierten Code zu erzeugen. Je nach Wissen und Gusto des Entwicklers.
Manchmal stolpere ich auf Stack Overflow über Threads, wo ein Blinder dem anderen Blinden über die Straße hilft....letztendlich lesen tausende Leute diesen Thread, aber etwas effektiv LERNEN wird da keiner. Man versucht halt, mit etlichen Varianten von Code die eine nachgefragte unverstandene Codevariante zu erklären..... 
Daher bin ich immer noch dafür, den C++-Code in einen Funktionsrahmen zu packen und als DLL zu kompilieren.
Außerdem sind DllStructs in AutoIt deutlich langsamer als z.B. Arrays
Was vor einiger Zeit geändert wurde. "Früher" war das gleich schnell, ich hatte mal einen Übersetzer geschrieben, der Arraycode in DllStruct-Code umgewandelt hatte, damit ich aus Assembler darauf zugreifen konnte.
Code der in C++ richtig schnell läuft muss komplett umstrukturiert werden um in AutoIt ebenfalls schnell zu laufen
Naja, mit Verlaub, ich lache 
Zwei nested loops mit einer x-beliebigen Funktion drin und Autoit ist Faktor 100 bis 1000 langsamer. Simple 5 Zeilen Code werfen dich Geschwindigkeitsmäßig auf einen 8088 mit 4.77 Mhz aus 1982 zurück....
Daher schreibe ich mir mein Script in AutoIt, suche den "inner loop" (der Programmteil, der 99% der Laufzeit mit Berechnungen verbrennt) und wandle nur diesen "inner loop" mit einer anderen x-beliebigen kompilierenden Programmiersprache in eine DLL oder schreibe den, just for fun, in Assembler. Einfach weil´s Spass macht....
Aber mal ganz ehrlich, wer schreibt ernsthaft SOLCHE Anwendungen in AutoIt?! Hehe, irgendwann hat sich hier der Ausdruck "Brotlose Kunst" etabliert! 
dann kann der Compiler auch automatisch sse verwenden, dann mag er 4x32er Blöcke lieber).
Ja, am meisten beeindruckt mich sowieso der Compiler, völlig unabhängig von der Syntax der Programmiersprache. Mittlerweile "erkennt" der Compiler, was der unglaublich schlechte Programmierer mit hingerotztem Scheißcode erreichen will und baut den Code so um, dass das Compilat extrem performant ist. Aber wie gesagt, da kann der Programmierer nix dafür!!!
Ich hatte über einen Bekannten vor einiger Zeit mal Zugriff auf einen INTEL-Compiler (als Privatmann kaufst du dir anstatt der Vollversion lieber ein Auto!)
Den hatten wir absichtlich mit "miesem" Code gefüttert und ich war echt von den Socken was letztendlich an Assemblercode ausgespuckt wurde.
Der hatte unsere absichtlich gebastelte array of structs (AoS) selbstständig in eine SoA umgewandelt, die unaligned im Speicher abgelegten Daten dann SSE-konform aufgedröselt und alles zusammen in (für mich) "wundeschönen" SIMD SSE-Code umgewandelt. Gleichzeitig noch die Goodies einer INTEL-CPU berücksichtigt und daraufhin optimiert.....da wurde mir dann klar, dass der Skill desjenigen, der blöd auf den Monitor glotzt und auf der Tastatur rumhämmert, letztendlich zweitrangig ist! Jedenfalls fast... 
Das ist kein Code den ich für irgendwas sinnvolles verwenden würde
Nana...ist doch ein schönes Beispiel wie so etwas "richtig" gelöst werden könnte 
Hehe, aber in letzter Zeit bist du AutoItscriptmäßig sowieso auf einem seltsamen "Trip"?! 
Mit "das größte Problem sind Datenstrukturen" habe ich natürlich ne steile These hingelegt. Sobald man mit "auto", "impl", Templates oder überladenen Operatoren anfängt (da weiß schon intellisense manchmal nicht mehr was der Code eigentlich macht) ist das Spiel sowieso vorbei 
Mit der Geschwindigkeit (also dass man Code ziemlich doll umschreiben muss damit er in AutoIt ebenfalls "schnell" läuft) habe ich "relative geschwindigkeit" gemeint. Natürlich ist AutoIt 1000x langsamer, wenn man mies übersetzt ist es aber 5000x.
Mein Trip endet, sobald meine aktuelle Aufgabe endet.
Dann kommt die nächste Aufgabe und damit der nächste Trip 
lg
M
meine aktuelle Aufgabe
Erzähl!
"C++ to VB Converter"
Aus welchem anderen Grund als "just for fun" sollte man so etwas machen?!
Autoit -> C(++) macht da wiederum Sinn, FALLS man die (wie angesprochen) 2 bis 3 verschachtelten FOR-Schleifen mit einigen mathematischen Berechnungen dazwischen etliche tausend mal schneller abwickeln möchte.
Der Interpreter ist das Bottleneck! Die WIN-API-Aufrufe laufen in AutoIt genau so schnell wie in einer beliebigen Compilersprache, wenn man sich darauf beschränkt, was die eigentliche Intension von AutoIt ist!!
Aber eine Compilersprache in eine andere "umzuwandeln", damit der Compiler daraus wiederum 99% identischen Maschinen-Code erzeugt ist imho sinnfrei! Es gibt auch nichts zu gewinnen, denn 100% aller "hardcore features" der "neuen" C++-Versionen sind in VB (oder einer anderen Sprache) nicht existent!
Der Ansatz von AutoIt->LLVM scheint mir dagegen wesentlich fruchtbarer....ohne LLVM gäbe es definitiv 90% der "neuen" esoterischen Sprachen NICHT! Ein bisschen "coole" Syntax zu "entwickeln" ist eine Sache, aber daraus dann wettbewerbsfähige Compiler zu schnitzen für x verschiedene (Prozessor-) Architekturen ist etwas anderes...
Wer sich für LLVM interessiert findet hier ein schönes und imho verständliches Beispiel! https://llvm.org/docs/tutorial/…tend/index.html
Damit gibt es m.E. nun ein hilfreiches Werkzeug den mitunter sehr kryptischen C++Code verstehen zu können, wenn man kein C++-Profi ist.
Hast du mal ChatGPT und Konsorten probiert?
Dort kannst du dem einfach den Code vor die Füße werfen und fragen: "Was macht dieser Code?"
Die Erläuterungen hierbei sind oft erstaunlich akkurat und das auch noch in humaner Sprache.
Ja, "sehr kryptischer C(++)-Code" war und ist schon immer das allergrößte Problem, auch der C++-Programmierer gewesen....wenn es "fancy" ist, solch coolen Code zu schreiben, den kaum ein anderer lesen kann, dann ist das einfach nur ärmlich.
Das hat auch definitiv nichts mit "Pro" zu tun, sondern damit, profilneurotisch den kurzen Bippes vertuschen zu wollen!
Dort kannst du dem einfach den Code vor die Füße werfen und fragen: "Was macht dieser Code?"
DAS lass ich lieber^^. DIESE Versuche habe ich hinter mir! Ich hatte mich kurz nach Veröffentlichung von ChatGPT mal einige Tage intensiv mit der Materie und vor allem den Ergebnissen auseinandergesetzt und bin zur Ansicht gekommen, dass ich 90% der Zeit gespart hätte, wenn ich mich statt mit ChatGPT mit dem Thema auseinandergesetzt hätte! Die "schnelle" Antwort mag sich ab und zu ja "gut" anhören/lesen, aber die Verifizierung braucht umso länger! Und warum verifizieren wenn ich doch direkt die Thematik an der Quelle be- bzw. abarbeiten kann?
Wenn ich Code ums verrecken nicht verstehe, dann ist der Code S C H E I S S E ! Wenn keine verständlichen Kommentare erklären was da vor sich geht und ich den Zusammenhang nirgendwo in einer Dokumentation finde, dann nützt mir der Code auch nichts?!
Ich lese Code ja nicht "just for fun" (ok, manchmal schon^^) sondern um etwas (neues) zu lernen oder zu sehen wie ein anderer das/mein Problem besser als ich gelöst hat. DAS bringt mich weiter. Leider ist "guter" aka lesbarer Code vom Aussterben bedroht, weil (so gut wie) nicht mehr auffindbar. Und zwar deswegen, weil 1000-fach gecopypasteter und "cool" abgeänderter und "professionell" aussehender Code gepostet wird. In diesem Sumpf dann die Perlen zu finden, ist echt schwierig....
Vor einigen Jahren, als Git noch in den Anfängen war und mehrheitlich von "echten" Profis genutzt wurde, konnte man zu bestimmten Themen zwar nur wenige, aber überwiegend brauchbare Treffer finden. Mittlerweile postet JEDER seinen Schrott dort und die Suche nach sinnvollen Beispielen endet meist im Frust.
Ich werde weitere Versuche unternehmen und berichten.
Bin gespannt!
