PHP to C++

Hallo!
Gibt es eine nicht ganz komplexe Möglichkeit PHP Skripte (in Verbindung mit HTML/CSS Ausgaben) in C++ zu übersetzen bzw. gibt es dafür schon Bibliotheken die HTML und/oder PHP interpreter anbieten?
Es handelt sich nicht um ein einzelnes Skript sondern um mehrere Dateien und Klassen. Somit fällt ein einfaches parsen - aufgrund der komplexen Vernetzung der Skripte - leider weg.
Eine Java-Lösung wäre mir auch sehr willkommen, auch wenn dies hier ein C++ Forum ist.

Ich nehme an dass ich nicht darum herumkommen werde, alles 1:1 zu übersetzen und Bibliotheken für die grafische Ausgabe zusammenzusuchen, aber jede hilfreiche Antwort ist mir willkommen!

was hast du genau vor? es gibt php-nach .exe compiler und auch so minimalumgebungen, die den PHP-interpreter ohne webserver hosten.

es gibt php-nach .exe compiler

Daran habe ich zuerst auch gedacht. Allerdings weiß ich nicht inwiefern dabei Interaktivität zwischen verschiedenen Skripten unterstützt wird.
Z.B. wenn ein Skript ein anderes aufruft und Zweiteres sich dann Variablen aus dem ersten holt. Oder Globale Variablen,...usw.
Außerdem steht dahinter noch eine SQL Datenbank, die ohnehin in eine eigene lokale Datenstruktur umgewandelt werden müsste.

Ich suche (Idealfalltechnisch betrachtet) eine einfache Möglichkeit das ganze Projekt vom Server loszulösen und als eigenständige exe laufen lassen zu können.
Falls es da Umgebungen geben sollte die PHP ohne Server lauffähig machen, wäre das auch eine Möglichkeit, allerdings wäre das ohne zusätzliche HTML Unterstützung auch hinfällig, weil es dann ohnehin zu einem PHP/C++ Merge führen würde und ich würde es bevorzugen mich zumindest zu 90% auf eine einzelne Sprache zu stützen. (Also eine Umgebung in C++ in welcher die PHP Skripte laufen). Denn durch das HTML-Ersetzen bräuchte es ohnehin wieder C++ Code und im Endeffekt wäre das dann eine 50% C++ 50% PHP Mischung, was u.U. vmtl zu unvorhersehbarem Verhalten führen könnte.

Oder anders gesagt:
Das ganze Projekt soll eine exe werden die ohne Server auskommt und dabei die gleichen Funktionen und Ausgaben bietet wie die PHP Skripte.

Hoffe das war etwas klarer

Lfh schrieb:

es gibt php-nach .exe compiler

Daran habe ich zuerst auch gedacht. Allerdings weiß ich nicht inwiefern dabei Interaktivität zwischen verschiedenen Skripten unterstützt wird.
Z.B. wenn ein Skript ein anderes aufruft und Zweiteres sich dann Variablen aus dem ersten holt. Oder Globale Variablen,...usw.
Außerdem steht dahinter noch eine SQL Datenbank, die ohnehin in eine eigene lokale Datenstruktur umgewandelt werden müsste.

Ich suche (Idealfalltechnisch betrachtet) eine einfache Möglichkeit das ganze Projekt vom Server loszulösen und als eigenständige exe laufen lassen zu können.
Falls es da Umgebungen geben sollte die PHP ohne Server lauffähig machen, wäre das auch eine Möglichkeit, allerdings wäre das ohne zusätzliche HTML Unterstützung auch hinfällig, weil es dann ohnehin zu einem PHP/C++ Merge führen würde und ich würde es bevorzugen mich zumindest zu 90% auf eine einzelne Sprache zu stützen. (Also eine Umgebung in C++ in welcher die PHP Skripte laufen). Denn durch das HTML-Ersetzen bräuchte es ohnehin wieder C++ Code und im Endeffekt wäre das dann eine 50% C++ 50% PHP Mischung, was u.U. vmtl zu unvorhersehbarem Verhalten führen könnte.

Oder anders gesagt:
Das ganze Projekt soll eine exe werden die ohne Server auskommt und dabei die gleichen Funktionen und Ausgaben bietet wie die PHP Skripte.

Hoffe das war etwas klarer

Und warum willst du C++ Code? Fraglich ist ja auch, ob ein solcher Compiler Quellcode generieren kann, der effizient bleibt... Am Besten wäre es sicher, wenn man das von Grund auf neuprogrammiert. Dann wäre auch die korrekte Funktionalität gewährleistet.

asdasd schrieb:

Und warum willst du C++ Code?

Kann auch Java sein. Das Ganze soll auf eine eigenständige exe hinauslaufen. Das ist das gewünschte Ziel.

asdasd schrieb:

Fraglich ist ja auch, ob ein solcher Compiler Quellcode generieren kann, der effizient bleibt... Am Besten wäre es sicher, wenn man das von Grund auf neuprogrammiert. Dann wäre auch die korrekte Funktionalität gewährleistet.

Eben exakt das denke ich mir auch, allerdings wollte ich hier nachfragen ob es denn zumindest hilfreiche, freie Bibliotheken gibt, um das Rad nicht für jede Funktion neu erfinden zu müssen. (Damit meine ich grafische Ausgabe ala html bzw im besten Fall eben einen html interpreter für c++)

Lfh schrieb:

asdasd schrieb:

Und warum willst du C++ Code?

Kann auch Java sein. Das Ganze soll auf eine eigenständige exe hinauslaufen. Das ist das gewünschte Ziel.

asdasd schrieb:

Fraglich ist ja auch, ob ein solcher Compiler Quellcode generieren kann, der effizient bleibt... Am Besten wäre es sicher, wenn man das von Grund auf neuprogrammiert. Dann wäre auch die korrekte Funktionalität gewährleistet.

Eben exakt das denke ich mir auch, allerdings wollte ich hier nachfragen ob es denn zumindest hilfreiche, freie Bibliotheken gibt, um das Rad nicht für jede Funktion neu erfinden zu müssen. (Damit meine ich grafische Ausgabe ala html bzw im besten Fall eben einen html interpreter für c++)

Ich hab eine Zeit gebraucht, um zu verstehen, was du jetzt konkret vor hast und wo deine Sorgen liegen... Sehe ich das richtig, dass du dir um die Oberfläche Sorgen machst, die du mit HTML gestaltet hast?

Diese Sorge ist durchaus berechtigt, da es in C++ einige großen Hürden gibt, um eine solche Oberfläche (GUI) zu realisieren. Eine solche GUI kann in der Regel auch mit HTML nichts anfangen und wird programmiert oder durch XML-Dateien gesteuert.

In Java sieht das zwar nicht anders aus, aber dort gibt es eine GUI, die du dir mit geeigneten Programmen auch zusammenclicken kannst. Die Unterstütztung ist also "von Haus" gesichert. Die unterschiedlichen Formulare können natürlich auch ihre Werte untereinander austauschen, so das eine "Verbindung" sichergestellt ist.

Alles in allem wirst du aber viel, vermutlich sogar alles, neuschreiben müssen. Einen Compiler der deinen Wünschen entspricht, gibt es wohl nicht.

Lfh schrieb:

asdasd schrieb:

Und warum willst du C++ Code?

Kann auch Java sein. Das Ganze soll auf eine eigenständige exe hinauslaufen. Das ist das gewünschte Ziel.

asdasd schrieb:

Fraglich ist ja auch, ob ein solcher Compiler Quellcode generieren kann, der effizient bleibt... Am Besten wäre es sicher, wenn man das von Grund auf neuprogrammiert. Dann wäre auch die korrekte Funktionalität gewährleistet.

Eben exakt das denke ich mir auch, allerdings wollte ich hier nachfragen ob es denn zumindest hilfreiche, freie Bibliotheken gibt, um das Rad nicht für jede Funktion neu erfinden zu müssen. (Damit meine ich grafische Ausgabe ala html bzw im besten Fall eben einen html interpreter für c++)

Ich hab eine Zeit gebraucht, um zu verstehen, was du jetzt konkret vor hast und wo deine Sorgen liegen... Sehe ich das richtig, dass du dir um die Oberfläche Sorgen machst, die du mit HTML gestaltet hast?

Diese Sorge ist durchaus berechtigt, da es in C++ einige großen Hürden gibt, um eine solche Oberfläche (GUI) zu realisieren. Eine solche GUI kann in der Regel auch mit HTML nichts anfangen und wird programmiert oder durch XML-Dateien gesteuert.

In Java sieht das zwar nicht anders aus, aber dort gibt es eine GUI, die du dir mit geeigneten Programmen auch zusammenclicken kannst. Die Unterstütztung ist also "von Haus" gesichert. Die unterschiedlichen Formulare können natürlich auch ihre Werte untereinander austauschen, so das eine "Verbindung" sichergestellt ist.

Alles in allem wirst du aber viel, vermutlich sogar alles, neuschreiben müssen. Einen Compiler der deinen Wünschen entspricht, gibt es wohl nicht.

Übrigens wird ein Java-Programm immer die JVM benötige, um zu laufen. Von einer tatsächlich eigenständigen exe, kann hier nicht die Rede sein. Jedoch ist Java eigentlich Standard und meistens überall vorhanden.

asdasd schrieb:

Ich hab eine Zeit gebraucht, um zu verstehen, was du jetzt konkret vor hast und wo deine Sorgen liegen... Sehe ich das richtig, dass du dir um die Oberfläche Sorgen machst, die du mit HTML gestaltet hast?

Exakt.

asdasd schrieb:

Diese Sorge ist durchaus berechtigt, da es in C++ einige großen Hürden gibt, um eine solche Oberfläche (GUI) zu realisieren. Eine solche GUI kann in der Regel auch mit HTML nichts anfangen und wird programmiert oder durch XML-Dateien gesteuert.

Das habe ich eben befürchtet. Die mächtigen Bibliotheken die hinter der Kombination PHP&HTML stehen lassen sich eben schwer nachprogrammieren, daher habe ich diesen Thread aufgemacht.

asdasd schrieb:

In Java sieht das zwar nicht anders aus, aber dort gibt es eine GUI, die du dir mit geeigneten Programmen auch zusammenclicken kannst. Die Unterstütztung ist also "von Haus" gesichert. Die unterschiedlichen Formulare können natürlich auch ihre Werte untereinander austauschen, so das eine "Verbindung" sichergestellt ist.

Java Swing habe ich mir auch schon angesehen. Im Moment versuche ich gerade noch herauszufinden was sich besser eignet... JavaSwing oder Qt, wxWidgets, GTKmm,...

asdasd schrieb:

Alles in allem wirst du aber viel, vermutlich sogar alles, neuschreiben müssen. Einen Compiler der deinen Wünschen entspricht, gibt es wohl nicht.

Damit habe ich eben gerechnet. Aber einen Versuch war es wert.

asdasd schrieb:

Übrigens wird ein Java-Programm immer die JVM benötige, um zu laufen. Von einer tatsächlich eigenständigen exe, kann hier nicht die Rede sein. Jedoch ist Java eigentlich Standard und meistens überall vorhanden.

Natürlich läuft die JVM im Hintergrund, aber für den Benutzer wirkt es im Endeffekt wie eine exe im Bezug auf Installation und Ausführen des Programms. Im Gegensatz zu der PHP, SQL, HTML, Browser Variante.

Falls Jmd noch Vorschläge bzgl Libs hat, würde ich mich freuen

Ad aCTa

Warum so eine Rückentwicklung auf C++?
Was stört dich am Webserver?
Wieso nutzt du nicht die CLI-Möglichkeiten von PHP? (Mit CLI meine ich nicht .NET, sondern Console Line Interface), Sprichwort: php.exe
Der PHP-Interpreter muss z.B. als CGI doch auch unabhängig vom Webserver laufen, es wird lediglich stdout auf den Webserver umgeleitet, wenn du es von ihm aus aufrufst. Bau eine kleine Exe, die php.exe (den Interpeter) aufruft und dann die Scripts abarbeitet.

Ad aCTa schrieb:

Warum so eine Rückentwicklung auf C++?
Was stört dich am Webserver?
Wieso nutzt du nicht die CLI-Möglichkeiten von PHP? (Mit CLI meine ich nicht .NET, sondern Console Line Interface), Sprichwort: php.exe
Der PHP-Interpreter muss z.B. als CGI doch auch unabhängig vom Webserver laufen, es wird lediglich stdout auf den Webserver umgeleitet, wenn du es von ihm aus aufrufst. Bau eine kleine Exe, die php.exe (den Interpeter) aufruft und dann die Scripts abarbeitet.

Dann hat er aber keine komfortable Oberfläche mehr, da diese durch HTML realisiert wurde.

Ad aCTa

Der IE kann bequem in ein Fenster eingebunden werden, dann kann man selbst noch die HTML-GUI benutzen. (Wenn sie denn für IE gemacht ist. *g*)

Ad aCTa schrieb:

Der IE kann bequem in ein Fenster eingebunden werden, dann kann man selbst noch die HTML-GUI benutzen. (Wenn sie denn für IE gemacht ist. *g*)

Und weiter? Wohin gehen die Daten des Formulars, wenn man den Submit-Button betätigt? Ich sehe hier eine Sackgasse.

Ad aCTa

Die Daten gehen in die Schnittstelle, in das Common Gateway Interface. Das Programm muss eben den erhaltenen String "?name=Hans&alter=45" dem Interpreter mitgegeben werden. Genau: in Form eines bestimmten Arrays, denn:

// So oder so ähnlich sähe die main-Funktion von php.exe aus.
// Die Regeln, wie env auszusehen hat, steht in der CGI-Spezifikation
int main(int argc, char** argv, char** env) {
}

Ich erkläre hier aber jetzt nicht CGI. Wozu man einen Browser neu programmieren sollte, verstehe ich nicht. Wenn die Anwendung wirklich so interaktiv ist, ist ein Portieren auf C++ Schwachsinn. Aber erst in PHP implementieren u. danach erst Binaries haben wollen, empfinde ich softwareentwicklungstechnisch als epic fail. Das sollte man sich in Schritt 2, Planung der Implementierung, klar machen und nicht erst nach Fertigstellung.

Ad aCTa schrieb:

Die Daten gehen in die Schnittstelle, in das Common Gateway Interface. Das Programm muss eben den erhaltenen String "?name=Hans&alter=45" dem Interpreter mitgegeben werden. Genau: in Form eines bestimmten Arrays, denn:
// So oder so ähnlich sähe die main-Funktion von php.exe aus.
// Die Regeln, wie env auszusehen hat, steht in der CGI-Spezifikation
int main(int argc, char** argv, char** env) {
}
Ich erkläre hier aber jetzt nicht CGI. Wozu man einen Browser neu programmieren sollte, verstehe ich nicht. Wenn die Anwendung wirklich so interaktiv ist, ist ein Portieren auf C++ Schwachsinn. Aber erst in PHP implementieren u. danach erst Binaries haben wollen, empfinde ich softwareentwicklungstechnisch als epic fail. Das sollte man sich in Schritt 2, Planung der Implementierung, klar machen und nicht erst nach Fertigstellung.

Mir ist klar, wie CGI funktioniert. Ich hatte schon selber einen Webserver mit CGI-Unterstützung programmiert. Das von dir beschriebene Vorgehen ist aber nicht ohne weiteres umsetzbar. Man müsste große Teile des PHP-Codes umschreiben und selbst dann würde es noch nicht reichen.

Oder wie willst du ein von der CLI ausgeführtes Script dazu bringen, dass es die CLI erneut startet und mit korrekten Parametern befüllt, sofern der Submit-Button betätigt wurde? Damit nicht genug. Auch diese Ausgabe muss an den Browser gesendet werden. Damit öffnest du das Tor zur Hölle Es ist so einfach nicht möglich.

Ad aCTa

> Damit nicht genug. Auch diese Ausgabe muss an den Browser gesendet werden. Damit öffnest du das Tor zur Hölle Es ist so einfach nicht möglich.

Klar ist das möglich. Ich kenne mich zugegeben vllt. nicht ganz so gut wie du aus, aber die php.exe gibt generierten HTML-Code an dein Programm zurück. Den gilt es einfach in die Renderengine vom embedded IE zu speisen, wenn das denn so geht. Der PHP-Code muss nicht verändert werden. Mit Click auf Submit muss die php.exe aufgerufen werden, die Env-Variablen müssen rein, der Quellcode, und die macht dann Magie. Der fertige HTML kommt hinten als C-String raus und den stopfst du in den IE zurück. Es ist Gefrickel. Es ist aufwändig. Es ist wie Webserver bauen, nur ohne Netzwerkfunkionalität. Aber das war zum Glück nicht mein Fehler. Die CLI erscheint mir als einfachster Anlaufspunkt. GUI, mein Gott. Die klickt man sich zusammen und baut daraus einen Querystring, dann bliebe einem sogar das IE-Gefrickel erspart.

Ad aCTa schrieb:

> Damit nicht genug. Auch diese Ausgabe muss an den Browser gesendet werden. Damit öffnest du das Tor zur Hölle Es ist so einfach nicht möglich.

Klar ist das möglich. Ich kenne mich zugegeben vllt. nicht ganz so gut wie du aus, aber die php.exe gibt generierten HTML-Code an dein Programm zurück. Den gilt es einfach in die Renderengine vom embedded IE zu speisen, wenn das denn so geht. Der PHP-Code muss nicht verändert werden. Mit Click auf Submit muss die php.exe aufgerufen werden, die Env-Variablen müssen rein, der Quellcode, und die macht dann Magie. Der fertige HTML kommt hinten als C-String raus und den stopfst du in den IE zurück. Es ist Gefrickel. Es ist aufwändig. Es ist wie Webserver bauen, nur ohne Netzwerkfunkionalität. Aber das war zum Glück nicht mein Fehler. Die CLI erscheint mir als einfachster Anlaufspunkt. GUI, mein Gott. Die klickt man sich zusammen und baut daraus einen Querystring, dann bliebe einem sogar das IE-Gefrickel erspart.

Es wird aber über mehrere Instanzen hinweg kritisch:

ControlProgram.exe -> PHP.exe -> PHP-Script -> PHP-Script -> PHP-Script

asdasd schrieb:

Ad aCTa schrieb:

> Damit nicht genug. Auch diese Ausgabe muss an den Browser gesendet werden. Damit öffnest du das Tor zur Hölle Es ist so einfach nicht möglich.

Klar ist das möglich. Ich kenne mich zugegeben vllt. nicht ganz so gut wie du aus, aber die php.exe gibt generierten HTML-Code an dein Programm zurück. Den gilt es einfach in die Renderengine vom embedded IE zu speisen, wenn das denn so geht. Der PHP-Code muss nicht verändert werden. Mit Click auf Submit muss die php.exe aufgerufen werden, die Env-Variablen müssen rein, der Quellcode, und die macht dann Magie. Der fertige HTML kommt hinten als C-String raus und den stopfst du in den IE zurück. Es ist Gefrickel. Es ist aufwändig. Es ist wie Webserver bauen, nur ohne Netzwerkfunkionalität. Aber das war zum Glück nicht mein Fehler. Die CLI erscheint mir als einfachster Anlaufspunkt. GUI, mein Gott. Die klickt man sich zusammen und baut daraus einen Querystring, dann bliebe einem sogar das IE-Gefrickel erspart.

Es wird aber über mehrere Instanzen hinweg kritisch:
ControlProgram.exe -> PHP.exe -> PHP-Script -> PHP-Script -> PHP-Script

Ah, genau genommen ist das falsch so, sry.

An dieser Stelle ist schon Feierabend:

ControlProgram.exe -> PHP.exe -> PHP-Script

Für das Folgescript müsst ewieder die PHP.exe aufgerufen werden.
Das Ergebnis müsste wiederum angezeigt werden, etc. Das ist mehr als gefrickel