nicht angemeldet
MySQL, PHP, cpp & Datenübergabe
Der MartinHallo,
ich möchte meine Webapplikation (PHP) mit einem cpp-Programm erweitern, welches rechenintensive Aufgaben erledigen soll, um damit den Server zu entlasten. Dazu brauch das cpp-Programm jedoch verschiedene Konfigvariablen aus der Webapp. Ich könnte diese auch gleich im cpp-Programm fest verankern, aber wenn sich an der Konfig mal etwas ändert, müsste ich dieses in der Webapp und im cpp-Programm ändern. Und das möchte ich vermeiden.
Daher speichere ich die Konfig in einer MySQL DB, auf die ich dann zugreife. Mit "einfachen" Variablen ist das auch kein Problem. Nur beinhaltet meine Konfig auch Arrays. Wie speichere ich die am besten? Mir würden nur 2 Sachen einfallen, entweder serializiert oder als JSON String. Mit was kommt cpp besser klar? Ich bin noch Anfänger in der cpp Programmierung und damit gerade etwas überfordert.
Also: Welches formatierte PHP Array wird in cpp am ehesten wieder zu dem originalen Array (Map, Set, Vector, ...)?!?
Bin für jede Hilfe dankbar.
MFG
Olli
-
Moin,
[..] Mir würden nur 2 Sachen einfallen, entweder serializiert oder als JSON String. Mit was kommt cpp besser klar? Ich bin noch Anfänger in der cpp Programmierung und damit gerade etwas überfordert.
Serialize auf Byte-Ebene, damit kommen sowohl php als auch cpp klar. Hier ein kleiner Algorithmus für ein Array in eine bin-Sequenz:
OPEN handle
FOREACH element
print length(element) > handle
print bytes(element) > handle
LOOP
CLOSE handleDu musst nur dafür sorgen, dass die Längenangaben stets eine konstante Anzahl an bytes haben, z.B. 4 byte (32 Bit) als Integer. Dann klappts auch mit der Wiederherstellung ;)
Hotti
--
Wenn meine Bücher veraltet sind, heitß das noch lange nicht, dass ich nicht mehr lesen kann.
-
Hi!
Serialize auf Byte-Ebene, damit kommen sowohl php als auch cpp klar.
Damit hat man Aufwand auf beiden Seiten, vor allem bei den komplexen Datentypen, weil man sich dabei auch mit Rekursion rumschlagen muss, um die Längenwerte von verschachtelten Strukturen zu ermitteln. Mit PHPs Serialisierung oder JSON kann man den einseitig oder beidseitig vermeiden. Und vor allem weiß man, dass beim Serialisieren schon an alles gedacht wurde. Obendrein sind beide Formate für Außenstehende wesentlich leichter nachzuvollziehen als Bytefolgen.
Lo!
-
Hi!
Serialize auf Byte-Ebene, damit kommen sowohl php als auch cpp klar.
Damit hat man Aufwand auf beiden Seiten, vor allem bei den komplexen Datentypen, weil man sich dabei auch mit Rekursion rumschlagen muss,
Eine Config, die rekursiv geparst werden muss, ist schlecht durchdacht.
Und vor allem weiß man, dass beim Serialisieren schon an alles gedacht wurde.
Es mag ja sein, dass in PHP an alles gedacht wurde ;)
Obendrein sind beide Formate für Außenstehende wesentlich leichter nachzuvollziehen als Bytefolgen.
Eine maschinenlesbare Konfiguration ist nicht für Außenstehende bestimmt.
Hotti
-
Hi!
Serialize auf Byte-Ebene, damit kommen sowohl php als auch cpp klar.
Damit hat man Aufwand auf beiden Seiten, vor allem bei den komplexen Datentypen, weil man sich dabei auch mit Rekursion rumschlagen muss,
Eine Config, die rekursiv geparst werden muss, ist schlecht durchdacht.Achwas. Alles flach zu strukurieren ist auch nicht der Weisheit letzter Schluss. Zudem schrieb er bereits, dass er Arrays hat, damit braucht er zumindest eine Iteration, um die Array-Gesamtgröße zu ermitteln. Zur Not reicht auch die Anzahl der Elemente. Aber dann hat man zwei mögliche length-Werte, einmal eine Größe in Byte und für das Array eine Anzahl. Wieder mehr Komplexität zum Preis, dass damit nicht alle möglichen Kombinationen von PHP-Variablen erschalgen werden. Damit hat deine einfache Binärlösung wieder einen Vorteil weniger. Gar keinen mehr hat sie, wenn man alles berücksichtigen will oder muss.
Obendrein sind beide Formate für Außenstehende wesentlich leichter nachzuvollziehen als Bytefolgen.
Eine maschinenlesbare Konfiguration ist nicht für Außenstehende bestimmt.Es geht mir dabei vor allem um nachfolgende Arbeiter an dem Projekt, oder andere Personen, die sich einarbeiten müssen. "Außenstehende" war nicht richtig formuliert.
Lo!
-
Hi!
Serialize auf Byte-Ebene, damit kommen sowohl php als auch cpp klar.
Damit hat man Aufwand auf beiden Seiten, vor allem bei den komplexen Datentypen, weil man sich dabei auch mit Rekursion rumschlagen muss,
Eine Config, die rekursiv geparst werden muss, ist schlecht durchdacht.Achwas. Alles flach zu strukurieren ist auch nicht der Weisheit letzter Schluss.
Eine Config, die rekursiv geparst werden muss ist nicht nur schlecht durchdacht, sondern unpraktikabel, wenn nicht sogar unbrauchbar. Best Practice: Die Daten stehen in festen Feldern like this:
'Authorization' => $cfg->{http}->{auth},Hast du dir mal eine 'objects.C' angeschaut? Das ist die Config einer Checkpoint-Firewall. Die ist 'flach' und somit gut zu parsen ohne Rekursion.
Zudem schrieb er bereits, dass er Arrays hat, damit braucht er zumindest eine Iteration,
folders => 'foo bar baz', da geht auch ein split um ein Array zu erzeugen.
Eine maschinenlesbare Konfiguration ist nicht für Außenstehende bestimmt.
Es geht mir dabei vor allem um nachfolgende Arbeiter an dem Projekt, oder andere Personen, die sich einarbeiten müssen. "Außenstehende" war nicht richtig formuliert.
Aber ich weiß was du meinst und irgendwie muss eine Config ja auch von der Tastatur kommen. Ich hatte mal genau dasselbe Problem, eine Config, die sowohl php als auch Perl lesen muss; das war im ersten Schritt eine ini-Datei, dafür gibt es in beiden Sprachen eine vorzügliche API. Allerdings musste ich ein Quoting einführen like
[/index]
title="Starseite der Webpräsenz"und bei vielen [URLs] ist das dann ätzend langsam geworden auf beiden Seiten php/Perl. Die ini-Datei habe ich beibehalten zum Editieren, aber es gab dann einen Zwischenschritt, der aus der ini eine maschinenlesbare Binary erzeugt hat und damit war die Performance ausgezeichnet.
Hotti
-
Hi!
Eine Config, die rekursiv geparst werden muss ist nicht nur schlecht durchdacht, sondern unpraktikabel, wenn nicht sogar unbrauchbar.
Das halte ich für völlig falsch. Schau mal ein /etc eines beliebigen Unix-Systems. Da findest du genügend Beispiele von Konfigurationsdateien, die nicht nur Key-Value-Auflistungen sind, und das sicherlich aus guten Gründen, weil eine flache Struktur "unpraktikabel, wenn nicht sogar unbrauchbar" gewesen wäre. Wenn man deine Argumentation mal weiterdenkt, müsste das eigentlich für alle Arten von Daten gelten, inklusive Dateisysteme. Es wäre äußerst unpraktisch, da nur unverschachtelte Strukturen zu erlauben.
Best Practice: Die Daten stehen in festen Feldern like this:
'Authorization' => $cfg->{http}->{auth},Und die festen Felder (auth) stehen angeordnet in Sektionen (http). Bei dieser einfachen Verschachtlung braucht man noch keine Rekursion. Aber was ist, wenn du noch weitere Verschachtlungsebenen brauchst, weil Untersektionen vielleicht doch für bestimmte Fälle praktisch wären?
Lo!
-
Hallo,
Eine Config, die rekursiv geparst werden muss ist nicht nur schlecht durchdacht, sondern unpraktikabel, wenn nicht sogar unbrauchbar.
Das halte ich für völlig falsch.ich auch.
Schau mal ein /etc eines beliebigen Unix-Systems.
Oder in about:config bei Firefox oder T-Bird, wo durch die Notation mehrerer mit einem Punkt getrennter Keywords ja auch eine logisch mehrstufige Struktur abgebildet wird. Die about:config-Auflistung *ist* dabei schon die serialisierte Form - obwohl ich die Anzeige als TreeView-Control wesentlich praktischer fände.
So long,
Martin--
F: Wer waren die ersten modernen Politiker?
A: Die Heiligen drei Könige. Sie legten die Arbeit nieder, zogen teure Klamotten an und gingen auf Reisen.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( -
Hi dedlfix!
Was ich schrieb:
Eine Config, die rekursiv geparst werden muss ist nicht nur schlecht durchdacht, sondern unpraktikabel, wenn nicht sogar unbrauchbar.
Dann schriebst Du:
Das halte ich für völlig falsch.
Und weiter oben schriebst Du:
Damit hat man Aufwand auf beiden Seiten, vor allem bei den komplexen Datentypen, weil man sich dabei auch mit Rekursion rumschlagen muss
Also wie jetzt???
-
Hi!
Was ich schrieb:
Eine Config, die rekursiv geparst werden muss ist nicht nur schlecht durchdacht, sondern unpraktikabel, wenn nicht sogar unbrauchbar.
Dann schriebst Du:
Das halte ich für völlig falsch.
Und weiter oben schriebst Du:
Damit hat man Aufwand auf beiden Seiten, vor allem bei den komplexen Datentypen, weil man sich dabei auch mit Rekursion rumschlagen muss
Also wie jetzt???
Den Aufwand minimieren, indem man soweit wie möglich vorgefertigte Komponenten für weithin anerkannte Verfahren und/oder Strukturen nimmt. Und wenn man was selbst schreibt: Obwohl Rekursion nicht unbedingt einfach ist, ist es keine generell gute Lösung, komplexe Strukturen flach aufbauen zu wollen.
Lo!
-
hi dedlfix,
Den Aufwand minimieren, indem man soweit wie möglich vorgefertigte Komponenten für weithin anerkannte Verfahren und/oder Strukturen nimmt.
Ja, da gebe ich Dir völlig Recht. Als Perler ist mein erster Weg CPAN, da gibts z.B. Config::IniFiles und weitere Module für Configurationsdateien.
ist es keine generell gute Lösung, komplexe Strukturen flach aufbauen zu wollen.
Auch richtig. Was für mich aber auch heißt, dass eine Config nicht unbedingt eine komplexe Struktur erfordert. Wenn ich eine Config bekomme, die Rekursionen erfordert, weil die so komplex ist, ist das eine andere Sache, als die Situation wo ich selbst eine Custom-Cfg entwerfe und die hat höchstens zwei Ebenen, was den direkten Zugriff, ohne Aufruf einer weiteren Methode ermöglicht:
$title = $cfg->{'/foo/bar'}->{title}
^REQUEST_URIAm Server musses schnell gehen, ein Methodenaufruf
$title = $cfg->suche_mir_mal_den_Titel_raus('/foo/bar')wird es bei mir nicht geben, solange ich das Scripten selbst in der Hand habe ;)
Grüße an alle, schönen Sonntag,
Hotti
-
-
-
-
-
-
-
-
-
Hi!
Nur beinhaltet meine Konfig auch Arrays. Wie speichere ich die am besten? Mir würden nur 2 Sachen einfallen, entweder serializiert oder als JSON String. Mit was kommt cpp besser klar?
Hast du dir mal beide Formate angeschaut? Es ist immer fortlaufender Text, nur auf die eine oder andere Art getrennt. Das heißt, es muss Text geparst werden. Das ist an sich nicht weiter tragisch, man muss es nur implementieren. Und da wird es vermutlich für JSON bereits eine Implementation geben, für die PHP-eigene Serialisierung schätze ich die Wahrscheinlichkeit geringer ein.
Also: Welches formatierte PHP Array wird in cpp am ehesten wieder zu dem originalen Array (Map, Set, Vector, ...)?!?
Generell ähneln PHP-Arrays am ehesten Dictionarys. Die Schlüssel können alle skalaren Werte PHPs sein, aber wenn du dich auf String festlegst, ist das üblicherweise ausreichend. Die Werte können alle PHP-Variablentypen sein, auch Arrays und Objekte. Und damit kann man beliebig tief und beliebig verzweigt schachteln. Das heißt also dass das Dictionary mit cen CPP-Typen für String als Key und Objekt als Schlüssel alles erschlägt. Wenn du allerdings weißt, dass dein Array doch eher einer spezialisierteren Form von Datensammlung ähnelt, dann ist es sicher besser, das in diese Form zu konvertieren, weil ein generischer Objekt-Typ ja nicht so prickelnd für die weitere Verarbeitung ist.
Lo!
-
Moin!
ich möchte meine Webapplikation (PHP) mit einem cpp-Programm erweitern, welches rechenintensive Aufgaben erledigen soll, um damit den Server zu entlasten. Dazu brauch das cpp-Programm jedoch verschiedene Konfigvariablen aus der Webapp. Ich könnte diese auch gleich im cpp-Programm fest verankern, aber wenn sich an der Konfig mal etwas ändert, müsste ich dieses in der Webapp und im cpp-Programm ändern. Und das möchte ich vermeiden.
Die Frage wäre, wie du dir überhaupt die Übertragung der Information "Mach jetzt mal diese konkrete Aufgabe" vorstellst.
Irgendwie muss dein cpp-Programm ja davon erfahren, was zu tun ist.
- Sven Rautenberg
-
Danke für die Antworten.
Ich habe JSON gewählt und als cpp Lib JSON Spirit. Funktioniert alles wie es soll :)