proggen.org

Hi, im Rahmen meines C++11- und SDL_net-basierten Netzwerk-Modules habe ich eine minimale JSON-Implementierung erstellt. Ihr findet den Code auf der verlinkten GitHub-Seite oder auch im Anhang dieses Posts.

Bisher verwende ich die JSON-Objekte wie folgt:
Xin kritisierte die Verwendung von Exceptions, die getX() wirft. Er persönlich mag keine Exceptions Sein Vorschlag war eine Art bool getString(std::string & result). Habt ihr noch andere Ideen für mich? Ich überlege die Implementierung abzuändern.

Btw habe ich absichtlich keine fertige JSON-Implementierung genommen, weil ich keine gefunden hatte, die "mir gefällt" ...

LG Glocke

Edit by Xin: Url-Tags korrigiert

Glocke hat geschrieben:Xin kritisierte die Verwendung von Exceptions, die getX() wirft. Er persönlich mag keine Exceptions Sein Vorschlag war eine Art bool getString(std::string & result). Habt ihr noch andere Ideen für mich? Ich überlege die Implementierung abzuändern.

Ich habe bei mir Funktionen häufig in Anlehnung anderer Sprachen als "asString" oder "asInt", die den entsprechenden Datentyp zurückliefern. Diese Funktionen gibt es aber nur dann, wenn sie garantiert eine entsprechende Repräsentation liefern können. Eine int-Variable würde also AsString() implementieren und dann auch einen String zurückliefern, zum Beispiel "4711".
Die Funktion heißt dann "AsString()", weil ich einen String haben möchte.

Im Falle von getString() ist der Typ schon durch die Variable genannt. Man könnte also überlegen, bool get( std::string & ) und bool get( int & ) zu überladen.
Ist nur eine Überlegung - keine Empfehlung. Die Nennung des Typens ist redundant, aber der Leser muss nicht erst den Datentyp der übergebenen Variablen prüfen.

Glocke hat geschrieben:Btw habe ich absichtlich keine fertige JSON-Implementierung genommen, weil ich keine gefunden hatte, die "mir gefällt" ...

Aktuell habe ich keine funktionierende Implementation mehr, weil ich ich das Mapping gerade umbaue und die Datenbank daran noch anpassen muss.
Die alte Version werde ich entsorgen, was nunmal auch meine derartige Implementation von JSON und XML killt.

Aber mal gucken, was die nächsten Tage bringen, ich hoffe am Wochenende wieder zum Programmieren zu kommen und wenn es soweit ist, bin ich auf Deine Meinung gespannt.

Xin hat geschrieben:Man könnte also überlegen, bool get( std::string & ) und bool get( int & ) zu überladen.
Ist nur eine Überlegung - keine Empfehlung. Die Nennung des Typens ist redundant, aber der Leser muss nicht erst den Datentyp der übergebenen Variablen prüfen.

Das gefällt mir!

Hast du noch einen Tipp für die interne Speicherung der Werte und des Typen? Bisher läuft das ja über ein Enum für den Typ und dann separate Membervariablen für die einzelnen Typen

Xin hat geschrieben:Aktuell habe ich keine funktionierende Implementation mehr, weil ich ich das Mapping gerade umbaue und die Datenbank daran noch anpassen muss.
Die alte Version werde ich entsorgen, was nunmal auch meine derartige Implementation von JSON und XML killt.

Aber mal gucken, was die nächsten Tage bringen, ich hoffe am Wochenende wieder zum Programmieren zu kommen und wenn es soweit ist, bin ich auf Deine Meinung gespannt.

Oki doki

LG Glocke

Glocke hat geschrieben:Hast du noch einen Tipp für die interne Speicherung der Werte und des Typen? Bisher läuft das ja über ein Enum für den Typ und dann separate Membervariablen für die einzelnen Typen

Wie gesagt - die Objekt(typ) Orientierung - machst Du über die "type"-Variable, was bei Erweiterungen nervig sein kann. Ich habe das gleiche Problem ja mit meinem Compiler, der Daten und Datentypen beim Interpretieren beisammen halten muss. Aber ich füge laufend neue Datentypen hinzu, da ist es halt praktisch, die gemeinsame Funktion in eine Basisklasse zu packen und solche Sachen wie dump() als pure virtual method anzubieten.

get ist dann virtuell und liefert in allen Varianten false zurück - jeder Datentyp überschreibt einfach seine Methode und liefert sich zurück.

Das Union würde ich Dir noch dringend empfehlen, wenn Du ohne Ableitungen weiterarbeiten möchtest (was durchaus auch Vorteile hat, insbesondere, wenn Du davon ausgehst, dass Deine Implementierung nicht um weitere Datentypen wächst)