Libelektra: Codegenerierung für Fehler

Persönlich bevorzuge ich Option 1. Die Fehlercodes sollten sich nur sehr selten ändern, wodurch der zusätzliche Aufwand, den C-Code manuell zu schreiben und andere Sprachen synchron zu halten, vernachlässigbar ist. Der anfängliche Aufwand sollte auch geringer sein im Vergleich zur Einrichtung jeglicher Form der automatischen Generierung.

Warum nicht Variante 2?

Moustache-Templates müssen irgendwie mit den Eingabedaten versorgt werden. Entweder müssen wir eine benutzerdefinierte ausführbare Datei verwenden, die zur Build-Zeit kompiliert wird. In diesem Fall würden wir nur std::cout << ... im C++-Code loswerden, aber sonst würde sich nicht viel ändern. Die andere Möglichkeit besteht darin, die standardmäßige ausführbare Schnurrbart-Datei zu verwenden, die ein Ruby-Skript ist und daher die Installation von Ruby erfordert.

Außerdem kann kdb gen nicht wiederverwendet werden, da dazu zuerst kdb kompiliert werden müsste, was kdberrors.h .

Warum nicht Variante 3?

Das Generieren des C-Codes funktioniert möglicherweise in CMake, aber komplexere Sprachen können Probleme bei der Verwendung von CMake haben.

Wenn wir uns für eine Form der Codegenerierung entscheiden, sollten wir nur die Teile generieren, die unbedingt generiert werden müssen. Zum Beispiel enthält das aktuelle kdberrors.h viel Code, der völlig statisch und unabhängig davon ist, welche Fehler wir tatsächlich haben. Dieser Code sollte nicht generiert werden, wir sollten ihn aus einer statischen Datei #include .

Ich bevorzuge auch Option 1 wegen stabiler Fehlercodes. Das Hinzufügen von Codegenerierung fügt dem Gesamtcode auch unnötige Komplexität hinzu, der wiederum fehleranfällig ist.

@kodebach danke für deine Ausarbeitung zu Option 2

Ich denke, es ist ziemlich klar, dass wir uns für Option 1 entscheiden, @Piankero, können Sie bitte die Entscheidung aufschreiben?

Für die Bindungen bedeutet das, dass sich nicht viel ändert.

Was wäre toll, wenn wir ein verbindliches Schreib-Tutorial hätten, das beschreibt:

1. welche Teile von Elektra Bindungen sinnvoll sind (Anwendung, Plugin, Tools, ...)
2. wie man Bindings in CMake integriert (wenn möglich und sinnvoll)
3. welche Teile der Bindungen für jede Sprache unterschiedlich sein können und sollen. Das beinhaltet:
   
   
   
   • Iteratoren
   
   
   • Konvertierung in native Typen (strings, int, ...)
   
   
   • Bedienerüberlastung (falls vorhanden)
   
   
   • andere Programmiersprachenintegrationen (Streams, Hashcodes, Identität, ...)
   
   
   • hat Fehler von kdb-Funktionen zurückgegeben (worum es bei diesem Problem hier geht)
   
   

Ich hoffe, wir können dieses Tutorial für die verschiedenen Situationen erweitern, die wir in verschiedenen Sprachen sehen. @Piankero können Sie bitte mit dem Schreiben des Tutorials beginnen, insbesondere des Abschnitts zur Fehlerbehandlung (wie man Vererbung implementiert, ...)

Tutorial: #2875
Designentscheidung: #2872