F
@Tuxist1 sagte in Implementation eigener Libstdc++:
@hustbaer gute Idee nach reiflicher Überlegung werde ich libcxx forken und von der libc abhängigkeit lösen.
Auch wenn ich von deinem Config-DB-Projekt nich wirklich überzeugt bin (bin kein Fan der Windows-Registry und immer froh wenn ich es mit Config-Dateien zu tun habe, die ich zur Not im Texteditor oder mit simplen Skripten anpassen kann):
Eine C++-Standardbibliothek, die lediglich einen Linux-Kernel oder auch nur ein paar selbst implementierte System-Calls benötigt (wie Newlib), ist durchaus eine äußerst interessante Idee. Wenn das gut funktioniert, dann könnte das z.B. für Embedded-Entwicklung sehr praktisch sein. Es ist bei mir etwas länger her, aber die kleinen Arduionos kann man auch in C++ programmieren. Die haben aber meines Wissens eine eigene C++Bibliothek implementiert - nicht wirklich die Standardbibliothek, aber etwas in die Richtung. Mit dem, was sie halt für ihr Ökosystem brauchen.
Auch würde ich vermuten, dass die libc++ nicht die schlechteste Wahl ist. Die ist gut getestet, weit verbreitet und auf Compiler- und Systemportabilität ausgelegt. Bei GNU-Projekten habe ich leider öfter den Eindruck gewonnen, dass die nicht selten sehr fixiert auf unixoide Systeme und das GNU-Ökosystem sind. Ich bin mir nichmal 100% sicher, ob sich die libstdc++ überhaupt mit Clang bauen lässt (vermutlich ja, aber das dürfte eher an der guten GCC-kompatibilität von Clang liegen... GNU Code nutzt gerne und viele GNU-spezifische Erweiterungen... nur so ne Erfahrung vom Zusammenstellen selbstgebauter Toolchains). libc++ lässt sich immerhin auch mit MSVC bauen. Das halte ich für ein gutes Zeichen, auch wenn ich deren Codebase nur vom Überfliegen her kenne.
Einfaches Beispiel zwei Programme die einen Konfiguration wert ändern können wie synchronisiere ich jetzt zum Beispiel den Zugriff.
Das sind wichtige Überlegungen. Wenn das was werden soll, dann muss das auf jeden Fall frei von Race Conditions sein, auch wenn dich zig Programme mit den schrottigsten Konfigurations-Aufrufen zuballern. Da braucht es auf jeden Fall einen Mechanismus um die Einträge atomar zu aktualisieren. Vermutlich auch irgendein Transaktions-System um die Konsistenz zu wahren, damit nicht zwei Programme widersprüchliche Änderungen an zwei verschiedenen Einstellungen machen die irgendwie gekoppelt sind und zusammen konsistent sein sollten ("featureA = disabled" und "use_for_operation = featureA").
Oder wie stelle ich sicher das ich mit einem Parser alle Config Files Bearbeiten kann, was bisher nie geklappt jedes Projekt hat einen eigenen würg.
Wäre es nicht schön mit einem einfachen Befehl die Konfiguration ändern zu können, Programm neustarten fertig.
Bisher muss man für jedes Programm nen eignenden Parser haben das macht doch keinen Sinn. Warum ist die Samba config anders als die zum Beispiel von Docker ? Obwohl sie das gleiche machen ?
Ich sehe wenig Chancen, all diese Projekte davon zu überzeugen auf dein System umzusteigen. Zumal solche Config-Sachen eine sehr grundlegende Funktion sind, die bei den meisten Projekten schon seit Urzeiten existiert und nicht einfach so ohne Not umgebaut werden wird. Der Effekt wird wahrscheinlich sein, dass dein Projekt dann eben zu einem "weiteren Config-Parser" wird, womit du ungewollt genau zu dem Problem beiträgst, was du eigentlich verbessern willst. Wenn das Erfolg haben soll, dann braucht es auf jeden Fall einen Mechanismus, mit dem man deine Config-DB auch ohne die Kooperation der Programm-Entwickler nutzen kann. Z.B. irgendein Interface, dass es für das Programm aussehen lässt, als würde es klassich auf eine /etc/config zugreifen, während im Hintergrund tatsächlich deine Config-DB dranhängt und die Zugriffe transparent übersetzt. Das wäre aber ein ziemlicher Akt, da du haufenweise Konfigurationsformate unterstützen müsstest. Ganz abgesehen von all den anderen Methoden, wie diese Config-Dateien bearbeitet werden können (Programm ruft Shell-Skript auf, dass /etc/config modifiziert oder Konfigurations-Tools wie z.B. Ansible machen dort Änderungen). Ganz abgesehen von den Millionen von User-Shellskripten (oder auch über Jahre gewachsene Skriptbibliotheken für sowas wie Ansible), die alle davon ausgehen, dass man die Config für XY über eine Textdatei in /etc/config macht.
Was allerdings eine Portierungs-Schicht für libc++ angeht, wo man ähnlich Newlib mit ein paar wenigen implementierten OS-Funktionen eine vollwertige C++-Standardbibliothek bekommt, da sehe ich eine deutlich größere Nachfrage. Wenn du das eh für dein Projekt vorhast, dann konzentrier dich doch erstmal auf sowas. Das ist schon Aufwand genug (auch wenn so eine C++Standardbibliothek wahrscheinlich nur einen Bruchteil einer vollwertigen libc nutzen dürfte) - da gehören nämlich z.B. u.a. auch solche Sachen wie eine malloc-Implementierung dazu (eigene oder vorhandene einbinden)
