Implementation eigener Libstdc++



  • Moin,

    bin gerade dabei eine eigene Standart Library für C++ zu schreiben hänge gerade an der atomic klasse wollte fragen ob jemand weiß wo es Dokumention zu den Low Level Typen gibt ?



  • @Tuxist1 Im C++ Standard steht alles.



  • @Tuxist1 sagte in Implementation eigener Libstdc++:

    bin gerade dabei eine eigene Standart Library für C++ zu schreiben hänge gerade an der atomic klasse wollte fragen ob jemand weiß wo es Dokumention zu den Low Level Typen gibt ?

    Warum macht man so etwas? Eine solche Aufgabe ist sehr aufwändig und voll mit Tücken.

    Nur mal so als Info: Visual Studio erlaubt bei allen Header Dateien einen Einblick. Da atomic ein Template ist, dürfte die komplette Implementierung im Header stehen. Und dieser Header ist bei mir cirka 3000 Zeilen groß. Und das dürfte nur die Spitze vom Eisberg sein.

    Ansonsten würde ich dir cppreference empfehlen.



  • @Tuxist1
    Apropo, mir ist da gerade eingefallen, das Microsoft seine STL Implementierung auf github stellte.

    Microsoft's C++ Standard Library



  • @Quiche-Lorraine sagte in Implementation eigener Libstdc++:

    @Tuxist1
    Apropo, mir ist da gerade eingefallen, das Microsoft seine STL Implementierung auf github stellte.

    Microsoft's C++ Standard Library

    Nice!



  • @Quiche-Lorraine weil ich gerade an einem C++ Userland für Linux arbeite. Wo ich eine Confdb gerade einbinde ist so ähnlich wie die Registrie unter Windows finde das der Ordner etc unter Linux katastrophal ist, für jedes Programm nen eignenden Parser das ist doch Wahnsinn wenn man eine grafische Konfigurationsoberfläche schreiben möchte. Confdb arbeitet auf Kernel ebene mit Syscalls. Sobald Stage 1 kompiliert werde ich ihn freigeben unter bsd Lizenz.



  • @Tuxist1 sagte in Implementation eigener Libstdc++:

    C++ Userland für Linux ... Kernel ebene mit Syscalls

    Ah... das wird für eine Laufzeit-Umgebung, in der man (noch) keine C-Standardbibliothek zur Verfügung hat auf der eine vorhandene C++-Standardbibliothek aufbauen könnte?

    Eine weniger mühsame Alternative könnte vielleicht sein, eine minimale libc wie Newlib oder picolibc zu verwenden und die als Basis für eine etablierte C++-Standardbibliothek (libc++/libstdc++) zu verwenden.

    Für die genannten libc-Implementierungen muss man lediglich eine Handvoll Systemfunktionen implementieren, den Rest macht die Bibliothek. Diese könnte man statisch verlinken und hätte dann auch ein Programm, dass unabhängig von einer vorhandenen (oder unvorhandenen) libc wäre.

    Vielleicht ginge auch eine statisch gelinkte libc mit einer Implementierung, die dafür ausgelegt ist (musl oder sowas).

    Nur so als Anregung, wie man das mit weniger Aufwand und ohne allzu viele Räder neu erfinden zu müssen hinbekommen könnte.



  • @Finnegan habe auch schon daran gedacht auf libc zu implementieren und musl zu forken. Vielleicht liege ich falsch mit meiner Einschätzung aber ich müsste vieles umbiegen, keine shadow,passwd datei etc.. , mein eigentliches ziel ist es keine Text Konfigurationsdateien mehr zu haben. ConfDB wo ich gerade auch bei bin ist ein Binärspeicher weil es nicht gewollt ist die Programme direkt drauf zugreifen.

    Klassisch ist es ja so

    C++ Programm:
    kernel <-> libc <-> libcxx <->Programm

    wollte es so lösen:
    kernel <-> libsystempp (stdlib und einige extensions sockets etc enthalten) <-> Programm

    auf Dateisystem ist das anders:

    klassisch:

    rootfs<->/etc/<->textfile<->libc/programm (locking muss im Programm bei konkurrierenden zugriff erfolgen)

    mein weg:

    rootfs<->kernel (mit Confdb)<->syscall<->libsystem<->programm (automatisches locking)

    Ob so was in den Kernel gehört ist natürlich diskussionswürdig aber denke das es für die Entwickler deutlich einfacher ist.



  • Eigene C++ Standard-Library schreiben macht keinen Sinn. Viel zu viel Aufwand und du wirst dabei viel zu viele Fehler einbauen. Fork eine der beiden grossen Implementierungen für Linux und bau das um was du umbauen musst.

    habe auch schon daran gedacht auf libc zu implementieren und musl zu forken.

    Wenn dein neues Userland POSIX sein soll, dann fork was bestehendes und bau es um. Bloss vielleicht nicht gerade musl. Und wenn es nicht POSIX sein soll, dann mach dich darauf gefasst dass dein neues Userland kaum jemand verwenden wird.

    Ob so was in den Kernel gehört ist natürlich diskussionswürdig aber denke das es für die Entwickler deutlich einfacher ist.

    Was soll da einfacher sein? Bzw. was wäre der Grund das überhaupt im Kernel haben zu wollen?



  • @hustbaer gute Idee nach reiflicher Überlegung werde ich libcxx forken und von der libc abhängigkeit lösen.

    Einfaches Beispiel zwei Programme die einen Konfiguration wert ändern können wie synchronisiere ich jetzt zum Beispiel den Zugriff.

    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 ?



  • @Tuxist1 sagte in Implementation eigener Libstdc++:

    Einfaches Beispiel zwei Programme die einen Konfiguration wert ändern können wie synchronisiere ich jetzt zum Beispiel den Zugriff.

    flock?

    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.

    Indem das einzige Interface zu dem Settings-Store eine Usermode Library ist.


    Du solltest auch nicht übersehen dass Textfiles auch nen riesen Vorteil haben, nämlich dass sie human-readable sind. Und ein Textfile pro Anwendung/Service hat auch Vorteile, nämlich dass es dann super einfach ist alle Settings eines Programms zu finden. Oder zu sichern/wiederherzustellen etc.



  • @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) 😉


Log in to reply