Come si fa a gestire le opzioni della riga di comando ei file di configurazione?

StackOverflow https://stackoverflow.com/questions/989980

Domanda

Quali pacchetti si usa per gestire le opzioni della riga di comando, le impostazioni ei file di configurazione?

Sono alla ricerca di qualcosa che si legge opzioni definite dall'utente dalla riga di comando e / o da file di configurazione.

Le opzioni (impostazioni) dovrebbero essere divisibile in gruppi diversi, in modo che possa passare diversi (sottoinsiemi di) opzioni per diversi oggetti nel mio codice.

Non conosco boost::program_options, ma non riesco ad abituarmi al API. Ci sono alternative leggeri?

(a proposito, usi mai un oggetto opzioni globali nel codice che può essere letto da qualsiasi luogo? Se non si considera che il male?)

È stato utile?

Soluzione

Bene, siete non piacerà la mia risposta. Io uso boost::program_options. L'interfaccia vuole un po 'per abituarsi, ma una volta che hai verso il basso, è incredibile. Basta fare in modo di fare carichi di test di unità, perché se si ottiene la sintassi sbagliata si ottenere gli errori di runtime.

E, sì, ho riporli in un oggetto Singleton (sola lettura). Io non credo che sia il male in quel caso. E 'uno dei pochi casi mi vengono in mente in cui un Singleton è accettabile.

Altri suggerimenti

In Google, usiamo gflags . Non fa i file di configurazione, ma per le bandiere, è molto meno doloroso rispetto all'utilizzo di getopt. 

#include <gflags/gflags.h>
DEFINE_string(server, "foo", "What server to connect to");
int main(int argc, char* argv[]) {
    google::ParseCommandLineFlags(&argc, &argv, true);
    if (!server.empty()) {
        Connect(server);
    }
}

Si mette il DEFINE_foo nella parte superiore del file che ha bisogno di conoscere il valore della bandiera. Se altri file anche bisogno di conoscere il valore, si utilizza DECLARE_foo in loro. C'è anche abbastanza un buon supporto per i test, in modo da unit test possono impostare diverse bandiere in modo indipendente.

Per le linee di comando e C ++, sono stato un fan di TCLAP:. Templatized riga di comando argomento parser

http://sourceforge.net/projects/tclap/

Se Boost è eccessivo per voi, GNU Gengetopt è probabilmente, troppo , ma IMHO, è uno strumento divertente per pasticciare con.

E, cerco di stare lontano da oggetti opzioni globali, io preferisco avere ciascuna classe di leggere la propria configurazione. Oltre l'intera filosofia "Global sono il male", tende a finire per diventare un caos sempre crescente di avere tutte le configurazioni in un unico luogo, e anche è più difficile dire che cosa le variabili di configurazione vengono utilizzati dove. Se si mantiene la configurazione più vicino a dove è in uso, è più evidente ciò che ognuno è per, e più facile da pulire.

(Per quanto riguarda quello che io uso, personalmente, per tutto quello che di recente è stata una linea di comando proprietaria parsing biblioteca che qualcun altro alla mia azienda ha scritto, ma che non ti aiuta molto, purtroppo)

Ho usato TCLAP per un anno o due ora, ma casualmente mi sono imbattuto in ezOptionParser . ezOptionParser non soffre "non dovrebbe deve essere in questo complesso" -syndrome stesso modo in cui altri parser Opzione.

Sono abbastanza impressionato finora e io probabilmente utilizzerò va avanti, proprio perché supporta i file di configurazione. TCLAP è una libreria più sofisticato, ma la semplicità e funzioni extra da ezOptionParser è molto interessante.

Altri vantaggi dal suo sito includono (al 0.2.0):

  • stampa piuttosto di ingressi analizzate per il debug.
  • Utilizzo automatico di creazione dei messaggi in tre layout (allineato, interlacciato o sfalsati).
  • implementazione del file di intestazione singolo.
  • dipende solo dalla STL.
  • nomi delle opzioni a breve e lungo arbitrarie (trattino '-' o più '+' prefissi non richiesta).
  • lista di argomenti arbitraria delimitatori.
  • casi di bandiera Permesso più.
  • La liquidazione di opzioni necessarie, numero di argomenti previsti per la bandiera, intervalli tipo di dati, definiti dall'utente gamme, l'appartenenza a liste e cassa per le liste di stringhe.
  • criteri di convalida definibili da stringhe o costanti.
  • l'importazione di file multipli con i commenti.
  • Le esportazioni di file, sia impostare opzioni o tutte le opzioni tra cui le impostazioni predefinite quando disponibile.
  • Index Option parse per ordine contesti dipendenti.

GNU getopt è abbastanza piacevole. Se si desidera un C ++ sensazione, in considerazione getoptpp che è un wrapper getopt nativo. Per quanto riguarda i file di configurazione è interessato, si dovrebbe cercare di rendere il più stupido possibile in modo che l'analisi è facile. Se siete po 'premuroso, si potrebbe desiderare di utilizzare yaac & lex, ma che sarebbe veramente un sacco di soldi per le piccole applicazioni.

Vorrei anche suggerire che si dovrebbe supportare sia i file di configurazione e le opzioni della riga di comando nella vostra applicazione. I file di configurazione sono migliori per quelle opzioni che devono essere cambiati meno frequentemente. le opzioni della riga di comando sono buoni quando si desidera passare gli argomenti mutevoli immediati (in genere quando si sta creando un app, che sarebbe stato chiamato da un altro programma.)

Se si lavora con Visual Studio 2005 su x86 e x64 di Windows c'è qualche buona utility a riga di comando parsing nel biblioteca SimpleLibPlus . L'ho usato e l'ho trovato molto utile.

Non è sicuro su riga di comando argomento di analisi. Non ho bisogno di funzionalità molto ricco di quella zona e in genere hanno rotolato la mia per salvare l'aggiunta di più dipendenze per il mio software. A seconda cosa i vostri bisogni sono si può o non può decidere di provare questo percorso. I programmi C ++ che ho scritto non sono generalmente invocati dalla riga di comando.

D'altra parte, per un file di configurazione si può davvero non battere un formato basato su XML. E 'leggibile, estensibile, strutturato, ecc ... :) In più ci sono un sacco di parser XML là fuori. Nonostante il fatto che è una libreria C, tendo a usare libxml2 da xmlsoft.org.

Apache Ant . Il suo utilizzo primario è progetti Java, ma non c'è nulla di Java su di esso, e la sua utilizzabile per quasi tutto.

:

L'utilizzo è abbastanza semplice e hai un sacco di sostegno della comunità anche. E 'veramente bravo a fare le cose nel modo in cui si sta chiedendo.

Per quanto riguarda le opzioni globali nel codice, penso che siano abbastanza necessario e utile. Non li uso improprio, però.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top