Konverter C++ Quellcode zu AutoIt-Skript

  • Mir sind da eine große Menge C++ Quellcode-Datein und Beschreibungen (-> https://www.geometrictools.com/index.html) in die Hände gefallen, die ich gern in AutoIt-Skripts übertragen möchte, weil diese vielleicht für mein Projekt "Wir bauen uns ein CAD" (hier im Forum vorgestellt) nützlich sein könnten. Eine händische Konvertierung ist sehr mühsam - deshalb meine Frage:

    Gibt es bereits einen solchen Konverter? - T.G. bringt nur den umgekehrten Fall, d.h. au3 -> Cpp.

    Grüsse aus Berlin

    PSblnkd

  • 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.

  • Andy

    Danke für Deine Hinweise, aber die gesamte Thematik ist doch dermaßen kompliziert, daß man - wie Du sinngemäß schreibst - schon ansatzweise "in's Schleudern" gerät. Bereits eine probeweise Compilation einzelner C++-Datein scheitert schon an irgendwelchem "Beiwerk", was da vielleicht noch gebraucht wird.

    Da lobe ich mir doch AutoIt!

    So einfach und schnell zielführend habe ich bis jetzt noch nichts Vergleichbares gefunden.

    Trotzdem würde es mich schon "jucken" so einen Code-Umsetzer zu programmieren - ist halt so ähnlich wie ein Compiler-Bau, Der konvertierte Code braucht ja nicht lauffähig zu sein, aber ansatzweise ein Übersetzung zur besseren Verständlichkeit wäre schon sehr hilfreich.

    Auch an eine Alternative für den SciTE mit eingebautem Debugger (Schrittbetrieb mit Marken und Variablen-Fenster) hatte ich schon gedacht ...

    Aber leider - die Zeit habe ich momentan nicht ... da hängt z.B. mein Mediathek-Projekt -> AutoIt-SQLite to HTML und "Wir bauen uns ein CAD" will ich auch irgendwann mal weiter bearbeiten ...

    Grüsse aus Berlin

    PSblnkd

  • 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.


    lg

    M

  • Gerade bei der Geometrieverarbeitung erwartet dich in AutoIt nur Trauer und Schmerz.

    :rofl:

    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 :P

    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..... :Face: :Glaskugel:

    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?! :Glaskugel: Hehe, irgendwann hat sich hier der Ausdruck "Brotlose Kunst" etabliert! :saint:

    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... :rock:

    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 :party:

    Hehe, aber in letzter Zeit bist du AutoItscriptmäßig sowieso auf einem seltsamen "Trip"?! :klatschen:

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    3 Mal editiert, zuletzt von Andy (3. November 2023 um 22:00)

  • 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 :D

    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!

  • Ein kleiner Hinweis als Nachtrag.
    Ich habe da einen "C++ to VB Converter" gefunden -> http://www.tangiblesoftwaresolutions.com/index.htm.
    Für eine Vollversion rufen die aber $-Preise auf, die meine "Taschengeld-Rente" nicht zulassen. Aber es gibt auch eine Freeware-Version, die jedoch Codezeilenanzahl-beschränkt ist. Somit geht die Konvertierung i.d.R. nur durch C&P für einzelne Funktionen. Ganze C++-Datein ziehen oft riesige Include-Datein hinterher, so daß die Zeilenbeschränkung schnell überschritten wird.
    Interessant ist aber die prinzipielle Erklärung der Funktionsweise in der auch in der Freeware-Version mitgelieferten "CPlus to VB Converter Help.chm".

    Da VB doch wesentlich näher an AutoIt ist als C++, könnte es vielleicht eine wertvolle Hilfe für einen "C++ to au3 Converter" sein. Vielleicht finde ich nochmal Zeit mich auch damit noch zu beschäftigen ...

    Grüssse aus Berlin

    PSblnkd

  • "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

  • Andy

    Danke für Deine Hinweise. Zwischenzeitlich habe ich mir diesen "C++toVB"-Converter mal etwas näher angeschaut, dh. die Help-Datei. Tatsächlich schreiben die dort, daß das ganze Verfahren sehr kompliziert ist, man sogar mit Heuristik arbeitet und trotzdem bleibt noch vieles offen ... d.h. ohne händische Nacharbeit wird's nicht gehen.

    Dann habe ich mal einen Konvertier-Versuch mit einer einfachen C++-Funktion gemacht und siehe da - mein Verständnis zur Funktionsweise dieser Funktion wurde massiv gestärkt. Natürlich kann man nicht davon ausgehen, dass die Konvertierung 1:1 sofort lauffähig ist. Wie ich schon im TO schrieb, geht es mir vordergründig um das tiefere Verständnis zu vorliegenden C++Codes. 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.

    Ich werde weitere Versuche unternehmen und berichten.

    Grüsse aus Berlin

    PSblnkd

  • 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!:theke:

  • So - weiterer Test!
    In der Freeware-Version geht nur eine begrenzte Anzahl Codezeilen, d.h. bei größeren Projekten muss man die Funktionen einzeln konvertieren. Hier ein Beispiel im Anhang (doc/zip-Datei).

    Im 1. ScreenShot ist die Funktionalität für ganze C++-Datein zu sehen, was aber in der Freeware-Version i.d.R. nicht geht, weil auch eingezogene include-Datein mitzählen.
    Der 2. ScreenShot zeigt die Funktionalität für sog. Code-Schnipsel - im allgemeinen Fall z.B. eine C++-Funktion - und das funktioniert auch in der Freeware-Version.

    Bei der Konvertierung -> siehe doc/zip-Datei, werden auch Kommentare (in englisch) eingefügt, wo der Konvertierer Probleme sieht.

    Also - ich bin eigentlich überrascht von dem m.A.n. doch recht brauchbaren Ergebnis - und nun Eure Meinung dazu.


    Grüsse aus Berlin

    PSblnkd