boost::program_options und die Praxis..

Anmerkung: Hierbei handelt es sich nicht um eine Frage, sondern nur um ein Bericht über boost::program_options.

Zu Beginn meines Projekts war ich ganz aus dem Häuschen wie genial boost::program_options (fortan po genannt) ist. Man kann leicht eine Config-Datei einlesen, optional noch Kommandozeilenargumente, Defaultwerte vergeben, hat Typsicherheit und eine Klasse Beschreibung für alle Parameter.
Zu Beginn war das Erste was ich wollte, das Erstellen einer Standard-Config-Datei, da po das nicht bietet, aber alle benötigten Informationen in der Beschreibung der Parameter (options_description hat einen op<< überladen, lässt sich also leicht verarbeiten), also lies sich das mit einem regulären Ausdruck recht leicht bewerkstelligen. Fortan gab es dann zwar einige Einschränkungen, sonst wäre das parsen zu kompliziert geworden, aber es lies sich gut damit leben.
Im Laufe der Zeit wurde es sehr nervig, wenn man in der Config-Datei noch ältere Optionen hat die es nicht mehr gibt, da po dann den Dienst verweigert (nicht unbedingt benutzerfreundlich, da er somit eine neue Datei erstellen lassen müsste und die alten Werte übertragen, oder sonst Arbeit hätte). Aber auch damit konnte
ich vorerst noch leben.
Aber gerade eben kam ich zu dem Punkt wo ich endlich einsehen musste, dass po nicht praxistauglich ist, denn die Länge die der Standardwert hat ist hart beschränkt (ca. 40Zeichen), wie soll man da einen Dateipfad speichern?

Ein weiterer großer Nachteil: man muss neu kompilieren wenn man eine Option hinzufügen oder entfernen oder irgendwie ändern möchte (hatte anfangs mal überlegt die Beschreibung in eine Datei auszulagern, aber da könnt man es gleich richtig machen).

Ich mag die boost libraries wirklich und für den ein oder anderen Zweck mag po auch ganz gut sein, aber für die ernsthafte Nutzung ist po einfach nicht gemacht. Möchte auch po hier nicht schlecht reden, aber ich denke es ist gut zu wissen woran man ist, wenn man po verwendet.

mfg Dr. Prof

C++ Forumbot

Dieser Thread wurde von Moderator/in evilissimo aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Artchi

Das die Parameter auf 40 Zeichen beschränkt sind, ist natürlich eine Frechheit - hab ich nämlich nicht gewusst (obwohl ich po einsetze). Hier sollte man wirklich mal den Entwickler in der Boost-Mailingliste anschreiben. Wir schreiben das Jahr 2006 und es wird anscheinend kein std::string für die Parameter genutzt?

Es gab vor ein paar Monaten ein Review für eine neue Lib namens Property Tree. Die sollte po indirekt Konkurrenz machen (was den Boostern nicht gefallen hat). Ich weiß leider nicht, wie das Review ausging und ob es somit aufgenommen wurde. Aber hier mal eine Kurzbeschreibung:

Introduction
------------

This fairly high-level library consists of the following
facilities:

1. a generic recursive property-tree data-structure

2. generic conversions to/from this data-structure from/to

a. xml-files

b. ini-flies

c. json-files

d. windows registry files

As an example of how powerful the library is, consider this
tutorial:

- http://kaalus.atspace.com/ptree/doc/index.html#five_minute_tutorial

The library may be downloaded from

- the boost file vault http://boost-consulting.com/vault/
(property_tree_rev5.zip)

- tinyurl: http://tinyurl.com/fkt7r

- boost sandbox: http://www.boost.org/more/mailing_lists.htm#sandbox
(look in boost/property_tree and libs/property_tree)

The documentation may be viewed online at

- http://kaalus.atspace.com/ptree/doc/index.html

If your find the above interesting, please consider submitting a review
to the boost developer mailing list:

- http://www.boost.org/more/mailing_lists.htm#main

You might end up using several hours on a review, but the end result
could be a superb library that will save you weeks of work.

Vielleicht hilft sie dir weiter und kann po ersetzen?

Die sieht ja wirklich klasse aus, muss mir nur mal näher anschauen wie da das mit den default-werten und so läuft.

Th

Also ich kann in den Boost-Sourcen von program_options nichts entdecken, das den Default-Value bei strings auf 40 beschränkt, da als generelle Klasse boost:any bzw. bei Texten std::string benutzt wird.

Der Fehler wird daher wohl woanders zu suchen sein...

.filmor

Einige Kommandozeileninterpreter schränken doch die Länge ein, oder?
Wie dem auch sei, meiner Meinung nach verfehlt ProgramOptions mit seinem Konfigurationsdatei-Kram sein Ziel. Eine Verbindung zwischen einer dafür geeigneten Bibliothek und po wäre natürlich praktisch, aber die komplette Verzahnung zu Einer ist Unsinn. Leider sehen das viele Booster anders ...

Das Assert wird in /src/options_description.cpp, line 436 ausgelöst.
Mit folgendem Test: line_length > first_column_width

Habe ich mit folgendem Eintrag erzeugt:

add_options()( "foo",
po::value< std::string >()->default_value("kjdsaflkhdsfhlksahfdhsadlhfskahf kjhsflkhdsaflsahflkhsadfhsalfhlks"),
"bla" );

Property Tree und der Ini-Parser sind zwar noch nicht perfekt, aber damit hab ich schonmal ne Grundlage, der Rest ist ja schnell erledigt

.filmor

Dr. Prof schrieb:

Das Assert wird in /src/options_description.cpp, line 436 ausgelöst.

Ach, nur ne Assertion? Stell dich doch nicht so an und kompilier mit NDEBUG

/edit Als ernstgemeinten Vorschlag könntest du einfach einen Patch machen, der das Ding umbricht. Das scheint ein Fehler der Ausgabe zu sein, die Bibliothek selber sollte mit derartigen Parametern klar kommen.

Das bringts nicht wirklich, dann frickel ich po nur noch mehr in mein programm rein, ich mach es jetzt einfach sauber mit Hilfe von property tree.

Möchte an dieser Stelle mal ein kleines Feedback zu boost::property_tree abgeben:
Prinzipiell ist property_tree ne sehr feine Sache, aber lohnt sich nicht wirklich, wenn man ein Format hat das keine echte Hierachie besitzt und man sich einen Parser selber schreiben muss.
Bei mir sah es am Ende so aus, dass ich quasi alles selber geschrieben habe und der property_tree unnötig war, habe dann einfach eine map< string, string > genommen.
Der Value ist als string, damit er leichter wieder gespeichert werden kann, was bei boost::any ja nur schwer möglich ist.

DEvent

Was macht ihr für komplezierte Sachen ?
Nehmt einfach einen XML-Parser und speichert solche config-Sachen in einen XML-Baum. Ich benutze für meine Programme seit Ewigkeiten jdom ( Java ) für Datenabspeicherung.
Dann habt ihr eine saubere Abspeicherung:

<config>
    <programmpfad>C:\My Programs\Fooo\</programmpfad>
    <hintergrund>C:\Meine Dokumente\Bilder\programmbild.jpg</hintergrund>
</config>

so als Beispiel.

Ja, nur ein normaler Benutzer findet ein vollbild = ein einfacher als eine xml-datei zu bearbeiten, das schreckt die Mehrheit ja schonmal ab, weil es kompliziert aussieht.
Deswegen verwende ich da lieber eine einfachere Syntax.

DEvent

Normalerweise sollten auch normal Sterbliche nicht in meinen Config-Dateien rumpfuschen. Alles was der Benutzer einstellen kann biete ich als einen Dialog an.

das schreckt die Mehrheit ja schonmal ab, weil es kompliziert aussieht.

Das ist doch ein Pluspunkt bei Config-Dateien.

Aber da deine Benutzer in der Config-Datei rumschreiben müssen, bist du bestimmt ein Linux-Anwender. Ich stell mal die These auf: Wer Linux zum laufen bringt, kann auch XML bearbeiten.
Ausserdem ist XML auch nur Text.

<config>
    <vollbild>ein</vollbild>
</config>

Naja stimmt, XML ist sehr kompliziert

DrGreenthumb

DEvent schrieb:

Normalerweise sollten auch normal Sterbliche nicht in meinen Config-Dateien rumpfuschen. Alles was der Benutzer einstellen kann biete ich als einen Dialog an.

typisch für schlechte windows-software.

Wer Linux zum laufen bringt, kann auch XML bearbeiten.

man kann, aber man will nicht.

DEvent

typisch für schlechte windows-software.

das musst du mir mal erklären

Blue-Tiger

DEvent schrieb:

typisch für schlechte windows-software.

das musst du mir mal erklären

Ich kann zwar nur fuer mich sprechen, aber:
IMO sollte das Programm an & fuer sich nur jene Einstellungsmoeglichkeiten bieten, die jeder DAU versteht. Un wer mehr veraendern will, schaut sich eben in der Konfig-Datei um.

DEvent

Blue-Tiger schrieb:

DEvent schrieb:

typisch für schlechte windows-software.

das musst du mir mal erklären

Ich kann zwar nur fuer mich sprechen, aber:
IMO sollte das Programm an & fuer sich nur jene Einstellungsmoeglichkeiten bieten, die jeder DAU versteht. Un wer mehr veraendern will, schaut sich eben in der Konfig-Datei um.

Ja das war doch meine Rede (Text).
In den Dialogen stelle ich die Konfiguration meines Programmes bereit. Wer mehr verändern will, der muss doch eh die Doku der config.dat anschauen.

Naja ich wollt nur sagen, benutzt einfach einen XML-Parser für die Config-Sachen.

DrGreenthumb

DEvent schrieb:

typisch für schlechte windows-software.

das musst du mir mal erklären

Von vielen Windows-Programmen ist man es gewohnt, die Einstellungen mit der Maus machen zu müssen, während die Konfiguration binär verschlüsselt ist. Ok, XML ist Text, aber trotzdem unangenehm zu bearbeiten.

Naja ich wollt nur sagen, benutzt einfach einen XML-Parser für die Config-Sachen.

Und ich wollte sagen, benutzt statt XML lieber ein von Menschen gut editierbares Format.

Es geht ja um Einstellungen die der Benutzer machen darf und nicht um Daten die nur irgendwie gespeichert werden müssen.

DEvent

Von vielen Windows-Programmen ist man es gewohnt, die Einstellungen mit der Maus machen zu müssen, während die Konfiguration binär verschlüsselt ist. Ok, XML ist Text, aber trotzdem unangenehm zu bearbeiten.

Einstellungen von einem Programm war nie verschlüsselt. Früher waren es die .ini Dateien, jetzt sind es meinst Reg-Schlüssel in der Windows-Registry.
Naja bin halt einer von diesen GUI-Verwöhnten, im 21. Jahrhundert lebenden User und nicht Text-is-the-Best-and-Only-Linux-Benutzer.

DrGreenthumb

DEvent schrieb:

Naja bin halt einer von diesen GUI-Verwöhnten, im 21. Jahrhundert lebenden User und nicht Text-is-the-Best-and-Only-Linux-Benutzer.

s/Verwöhnt/Gebunden/
Und von only war ja keine Rede.

Aber egal. Fazit: Du schlägst XML vor und ich finds unpassend.