Hallo, ich bräuchte mal eine Empfehlung für eine Configfile-library unter Linux für C (C++ wäre auch nett aber primär gehts mir um C). Mir sind bislang libconfig und libconfuse über den Weg gelaufen, gibts weitere Empfehlungen, oder auch eine Empfehlung zu einer der beiden Libs? Wichtig wäre für mich auch, dass die Lib nicht einen Rattenschwanz an weiteren Abhängigkeiten nach sich zieht.
Sowas triviales schreibt man sich selbst. Wenn du ne Textdatei mit Key=value pasrsen nicht selber hinbekommst wechsel den Job.
Internatszögling schrieb: > Sowas triviales schreibt man sich selbst. > Wenn du ne Textdatei mit > Key=value > pasrsen nicht selber hinbekommst wechsel den Job. Genau so macht man es eben nicht. Hab sowas vor 20 Jahren selber geschrieben und für die damaligen Aufgaben war das auch ok, aber es war doch jeweils eher für das konkrete Problem zusammengestrickt. Warum sollte man heute nicht eine der bereits tausendfach erprobten Libs dafür nehmen und jedesmal das Rad neu erfinden? Geh doch einfach mal davon aus das in einem Configfile mehr drin stehen kann als einfache Keyvalue-Paare und das es eventuell auch darum gibt das Dritte darin rumfuhrwerken und an bei dir nicht vorgesehener Stelle Kommentare, Leerzeichen oder sonstwas einfügen das sie von anderen Configfiles gewohnt sind...
Aktuell sind die von Hippstern bevorzuge Config-Fileformate json und yaml (yaml ist eine Obermenge von json). Für beide Formate bekommst du Bibliotheken nachgeworfen. Eine kleine Auswahl von yaml-Parsern findest du auf https://yaml.org/ Eine kleine Auswahl von json-Parsern findest du auf https://www.json.org/ Es gibt mehr als die dort aufgeführten, also --> Google.
Hannes J. schrieb: > Aktuell sind die von Hippstern bevorzuge Config-Fileformate json und > yaml (yaml ist eine Obermenge von json). Für beide Formate bekommst du > Bibliotheken nachgeworfen. > > Eine kleine Auswahl von yaml-Parsern findest du auf https://yaml.org/ > Eine kleine Auswahl von json-Parsern findest du auf > https://www.json.org/ > > Es gibt mehr als die dort aufgeführten, also --> Google. Also nochmal, es geht mir nicht um Serializer, es geht mir um Configfiles. Das es Leute gibt die Json, XML oder auch sonstwas für Configfiles benutzen ändert nichts daran das es bei diesen Formaten um Datenaustausch zwischen Maschinen geht die (bedingt) Menschenlesbar ist, nicht um Einstellungen die von einem Menschen vorgenommen werden.
Tim T. schrieb: > Also nochmal, es geht mir nicht um Serializer, es geht mir um > Configfiles. Das es Leute gibt die Json, XML oder auch sonstwas für > Configfiles benutzen ändert nichts daran das es bei diesen Formaten um > Datenaustausch zwischen Maschinen geht die (bedingt) Menschenlesbar ist, > nicht um Einstellungen die von einem Menschen vorgenommen werden. ok, was sind denn die speziellen Anforderungen an Configfiles die über Daten strukturiert in eine Datei schreiben und wieder lesen hinausgehen?
Tim T. schrieb: > > Also nochmal, es geht mir nicht um Serializer, es geht mir um > Configfiles. Das es Leute gibt die Json, XML oder auch sonstwas für > Configfiles benutzen ändert nichts daran das es bei diesen Formaten um > Datenaustausch zwischen Maschinen geht die (bedingt) Menschenlesbar ist, > nicht um Einstellungen die von einem Menschen vorgenommen werden. Und gerade deshalb verwende ich bei meinen Config-Files nur noch json. Die Bibliotheken sind stabil. Das Parsen geht einfach. Der Mensch kann das noch verstehen. Es sind Strukturen und Arrays möglich. Die Konfiguration läuft über ein GUI. Intern ist es Json. Und Erfahrene können dort noch von Hand edieren.
Tim T. schrieb: > Also nochmal, es geht mir nicht um Serializer, es geht mir um > Configfiles. Das es Leute gibt die Json, XML oder auch sonstwas für > Configfiles benutzen ändert nichts daran das es bei diesen Formaten um > Datenaustausch zwischen Maschinen geht die (bedingt) Menschenlesbar ist, > nicht um Einstellungen die von einem Menschen vorgenommen werden. Jetzt tu mal nicht so wichtig, ja? Json und yaml werden haufenweise von Menschen verwendet um Einstellungen vorzunehmen. Besonders yaml, weil man dort bewusst noch die Klammern von json entfernt hat. Das sind sicher nicht die schönsten Formate aber sie sind sehr gängig. Zum Beispiel beschreibt man heutzutage ganze Kubernetes-Cluster mit yaml. Und was soll dein Scheiß mit Serializer? Jede Configfile-Datenstruktur, auch wenn sie noch so flach ist (Key-Value), wird von der zugehörigen Bibliothek "serialisiert" = hintereinander in ein Textfile geschrieben. Beim Einlesen wird dann wieder die ursprüngliche Datenstruktur hergestellt. Egal ob eine primitive Key-Value Struktur oder etwas hierarchisches. Einige von den vorgeschlagenen Bibliotheken bieten an direkt auf Elemente über den Element-Pfad zuzugreifen, so dass man sich nicht durch eine hierarchische Datenstruktur hangeln muss. Aber da war der Herr ja zu fein für sich das mal anzusehen. Wenn du so ein Held bist, warum schreibst du dir deine Bibliothek nicht mundgerecht selber?
Tim T. schrieb: > nicht um Einstellungen die von einem Menschen vorgenommen werden. Zeig mir bitte 1 Config-Format, das bevorzugt von Menschen verändert werden soll. JSON ist schon ganz gut, da es mit einfachen Datentypen umgehen kann. SQLite wird auch für sowas verwendet. Ansonsten schau mal was das von dir verwendete Framework kann. z.B. gibt's QSettings von der Qt sind i.O. und verwenden je nach Plattform die dort bevorzugte Ablageart. Alternativ gäbe es noch Boost.Program_options für ini-files... Ich habe aber sogar mal eine JS-Script Engine angeworfen für config-files. Das geht in der Qt mit ein paar Zeilen. Die Parameter waren dann quasi globale Objekte im Script. Damit waren ganz einfach auch Berechnungen in der Config möglich. Kann extrem konfortabel sein, wenn man's gerade braucht... "Config-File" kann halt von einer Apache config bis zu einem einfachen ini-file alles sein... 73
Tim T. schrieb: > Mir sind bislang > libconfig und libconfuse über den Weg gelaufen, gibts weitere > Empfehlungen, oder auch eine Empfehlung zu einer der beiden Libs? Ich habe libconfig mit C im Einsatz und bin an sich zufrieden damit. Tut was es soll, ist unauffällig und einfach zu verwenden. Hannes J. schrieb: > Aktuell sind die von Hippstern bevorzuge Config-Fileformate json und > yaml (yaml ist eine Obermenge von json). Für beide Formate bekommst du > Bibliotheken nachgeworfen. Wobei json den gravierenden Nachteil hat, dass sie vergessen haben, Kommentare zu unterstützen. Gerade in Config-Files nutze ich Kommentare sehr intensiv, um alle Optionen im Detail zu erklären, ähnlich wie es bei den meisten OpenSource-Programmen ist. Es gibt auch noch TOML. Das ist dem klassischen ini-Format sehr ähnlich, aber im Gegensatz zu diesem klar definiert. Internatszögling schrieb: > Sowas triviales schreibt man sich selbst. Nur wenn man grad nix besseres zu tun hat oder man so spezielle Anforderungen hat, dass bestehende Lösungen nicht in Frage kommen. > Wenn du ne Textdatei mit > Key=value > pasrsen nicht selber hinbekommst wechsel den Job. Wenn du dich dazu berufen fühlst, solchen Nebenkram stets selbst zu schreiben, statt einfach eine fertige Lib zu verwenden, wechsel den Job.
Hannes J. schrieb: > Tim T. schrieb: >> Also nochmal, es geht mir nicht um Serializer, es geht mir um >> Configfiles. Das es Leute gibt die Json, XML oder auch sonstwas für >> Configfiles benutzen ändert nichts daran das es bei diesen Formaten um >> Datenaustausch zwischen Maschinen geht die (bedingt) Menschenlesbar ist, >> nicht um Einstellungen die von einem Menschen vorgenommen werden. > > Jetzt tu mal nicht so wichtig, ja? > > Json und yaml werden haufenweise von Menschen verwendet um Einstellungen > vorzunehmen. Besonders yaml, weil man dort bewusst noch die Klammern von > json entfernt hat. Und Millionen Fliegen fressen Scheiße, muss also was dran sein, oder? > Das sind sicher nicht die schönsten Formate aber sie sind sehr gängig. > Zum Beispiel beschreibt man heutzutage ganze Kubernetes-Cluster mit > yaml. Ich bestreite nicht das Json oder auch XML ihre Berechtigung haben, nutze es selber sowohl für den Datenaustausch als auch zur Ablage von großen Mengen an Parameterdaten die nur mit anderer Software geändert werden, aber fürs händische ändern sind sie nicht brauchbar. > Und was soll dein Scheiß mit Serializer? Jede Configfile-Datenstruktur, > auch wenn sie noch so flach ist (Key-Value), wird von der zugehörigen > Bibliothek "serialisiert" = hintereinander in ein Textfile geschrieben. > Beim Einlesen wird dann wieder die ursprüngliche Datenstruktur > hergestellt. Egal ob eine primitive Key-Value Struktur oder etwas > hierarchisches. Es ging mir dabei bewusst um den Automatismus, das am Ende nur etwas irgendwie in ein File geklatscht wird, ohne auf die üblichen menschlichen Befindlichkeiten Rücksicht zu nehmen. JSON und XML sind eben nicht dafür gedacht das sie gewöhnlich von Menschen direkt modifiziert werden, nur das es eben, wenn auch umständlich, zur Not geht. > Einige von den vorgeschlagenen Bibliotheken bieten an direkt auf > Elemente über den Element-Pfad zuzugreifen, so dass man sich nicht durch > eine hierarchische Datenstruktur hangeln muss. Aber da war der Herr ja > zu fein für sich das mal anzusehen. Und, nur weil es nicht maximal umständlich ist, wirds brauchbar? > Wenn du so ein Held bist, warum schreibst du dir deine Bibliothek nicht > mundgerecht selber? Weil es die z.B. mit libconfig und libconfuse schon gibt, bin nur auf der Suche ob es noch was besseres für den angedachten Zweck gibt oder die beiden Libs irgendwelche gravierenden Nachteile besitzen die erst später auffallen.
Hans W. schrieb: > Tim T. schrieb: >> nicht um Einstellungen die von einem Menschen vorgenommen werden. > > Zeig mir bitte 1 Config-Format, das bevorzugt von Menschen verändert > werden soll. In meinen Augen schon das was bei libconfig oder libconfuse rausfällt. > JSON ist schon ganz gut, da es mit einfachen Datentypen umgehen kann. > SQLite wird auch für sowas verwendet. JSON verwende ich auch, aber als Configfile finde ich es ungeeignet. SQLite habe ich in der Vergangenheit auch schon genutzt, nur fiele mir im Traum nicht ein das für eine einfach zu ändernde Einstellungen zu nutzen. > Ansonsten schau mal was das von dir verwendete Framework kann. Die meisten Frameworks die ich benutze können alles Mögliche, ist also nicht die Einschränkung, will es allerdings auch ganz normal in C Anwendungen ohne irgendwelche Frameworks und auf minimalen Embedded Systemen nutzen können. > z.B. gibt's QSettings von der Qt sind i.O. und verwenden je nach > Plattform die dort bevorzugte Ablageart. > Alternativ gäbe es noch Boost.Program_options für ini-files... Boost und QT gehen alleine schon in die völlig falsche Richtung. > Ich habe aber sogar mal eine JS-Script Engine angeworfen für > config-files. > Das geht in der Qt mit ein paar Zeilen. > Die Parameter waren dann quasi globale Objekte im Script. > Damit waren ganz einfach auch Berechnungen in der Config möglich. > Kann extrem konfortabel sein, wenn man's gerade braucht... > > "Config-File" kann halt von einer Apache config bis zu einem einfachen > ini-file alles sein... > Für solche Sachen kann ich auch Json oder sonstwas nehmen, geht mir eher ums andere Ende der Fahnenstange.
Rolf M. schrieb: > Wenn du dich dazu berufen fühlst, solchen Nebenkram stets selbst zu > schreiben, statt einfach eine fertige Lib zu verwenden, wechsel den Job. Nö, Leute die sich auch noch um so etwas Gedanken machen sind fähiger als die Lib-Jongleure. Ob eine Lib wirklich passt, weiß man erst wenn man sie mal probiert hat. Und spätestens wenn mal ein Regex-Ausdruck mit rein soll oder etwas ähnliches wird geflucht wenn gerade diese Konstellation die Lib nicht unterstützt. Und wenn man erst noch in einem Forum nach einer Lib betteln geht, hätte man das besser gleich selbst gemacht oder schon lange im Kasten. Es ist ja nicht nur die Lib selbst. Wenn die auch wieder Abhängigkeiten zu anderen hat, und gerade bei xml, dann kommt man schnell ans Fluchen. Oder man hat 3 unterschiedliche xml-Parser im Projekt weil die eine Lib was anderes in den Abhängigkeiten hat als die andere. JSON sehe ich auch für nicht optimal an wegen der fehlenden Kommentare. Da müsste man dann vor dem JSON-Parsen die Kommentare selbst entfernen. Bleibt die zwar einfache aber trotzdem nervige Syntax wenn man das von Hand schreiben muss. Ich bleibe bei Konfigurationsdateien beim ini-Format und einem selbst geschriebenen Parser. Die paar Zeilen Code die dazu nötig sind gehen als Fingerübung durch.
temp schrieb: > Rolf M. schrieb: >> Wenn du dich dazu berufen fühlst, solchen Nebenkram stets selbst zu >> schreiben, statt einfach eine fertige Lib zu verwenden, wechsel den Job. > > Nö, Leute die sich auch noch um so etwas Gedanken machen sind fähiger > als die Lib-Jongleure. Fähige Leute konzentrieren sich auf die zu lösende Aufgabe statt auf irgendwelches Drumherum. Sie müssen niemandem beweisen, dass sie solche Sachen auch umsetzen können. > Ob eine Lib wirklich passt, weiß man erst wenn man sie mal probiert hat. Deshalb fragt der TE ja nach Erfahrungsberichten von Leuten, die das getan haben. > Und spätestens wenn mal ein Regex-Ausdruck mit rein soll oder etwas > ähnliches wird geflucht wenn gerade diese Konstellation die Lib nicht > unterstützt. Ein regulärer Ausdruck, der vom Config-Parser selbst bereits ausgewertet werden muss? > Es ist ja nicht nur die Lib selbst. Wenn die auch wieder Abhängigkeiten > zu anderen hat, und gerade bei xml, dann kommt man schnell ans Fluchen. libconfig als Beispiel hat keine Abhängigkeiten, außer Standard-C.
Rolf M. schrieb: > Ein regulärer Ausdruck, der vom Config-Parser selbst bereits ausgewertet > werden muss? Nein, einen beliebigen String mit cryptischer Syntax die der config-Parser nicht als Kommetar oder sonstwas ansieht oder anderweitig drüber stolpert. Mag ja bei libconfig gegeben sein, aber wir diskutieren hier nicht über eine einzelne lib. Und nicht jeder braucht/will C-Syntax in configurations-Dateien mit Hochkommazwang und Semikolons. Klar ist das schick für umfangreiche Konfigurationen. Der weitaus größere Teil ist aber absolut simpel und da reicht der Syntax ala ini-File aus.
Tim T. schrieb: > C nicht C++, Configfile nicht Serializer... Du schriebst doch C++ wäre nett?! Und würdest du dir den Krempel anschauen, dann würdest du sehen, dass genau das damit geht. Nicht nur INI Files sind Config Files Ausserdem mappt dir das deine Configfiles auch direkt auf deine Objekte. Aber naja, gibt sicherlich auch noch x andere Lösungen https://github.com/benhoyt/inih
Rolf M. schrieb: > Wenn du dich dazu berufen fühlst, solchen Nebenkram stets selbst zu > schreiben, statt einfach eine fertige Lib zu verwenden, wechsel den Job. Während du immer noch suchst haben andere diese Trivialität schon lange fertig geschrieben. Bei den Vorschlägen passt dir diess nicht, jenes nicht,... selber schreiben kommt auch nicht in Frage, tja dann wird das eben nix.
Tim T. schrieb: > Warum > sollte man heute nicht eine der bereits tausendfach erprobten Libs dafür > nehmen und jedesmal das Rad neu erfinden? Benutze Windows und schreib deinen Krempel in die Registry. W.S.
funky schrieb: > Tim T. schrieb: >> C nicht C++, Configfile nicht Serializer... > > Du schriebst doch C++ wäre nett?! > Und würdest du dir den Krempel anschauen, dann würdest du sehen, dass > genau das damit geht. Nicht nur INI Files sind Config Files Ja, C++ wäre nett aber C ist ein Muss. Wobei einfache Configfiles in C++ auch mit der STL gehen, hab ich sogar noch irgendwo liegen. Btw. hab mittlerweile das Ganze mit libconfig gemacht und soweit scheint es alles zu erfüllen was ich gesucht habe, die Zukunft wird zeigen ob es irgendwo doch noch Gründe gibt etwas Anderes zu benutzen. Danke nochmal an Rolf M., der als Einziger etwas brauchbares hierzu beigetragen hat. Von mir aus kann der Thread jetzt gerne zugemacht werden, sinnvoller wirds hier wohl eh nicht mehr.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.