Subject: Re: [boost] Boost.Application
From: Christof Donat (cd_at_[hidden])
Date: 2012-01-26 04:56:21
>> When writing an application, how do I use boost::program_options to
>> parse a
>> std::vector< std::string >? At least I have not found any overloaded
>> of parse_command_line(). Maybe I have just not seen it.
> The tutorial explains this. Also, see main_tutorial_3.cpp.
I see, thanks. I don't like it, though I don't have an alternative
solution at hand. Somehow this feels very clumsy with that init()
method. As example of a pure OO approach you could have a look at Qts
QApplication. That one gets argc and argv as constructor parameters. Yet
I do like the idea of using a vector< string > instead of the C like
argc and argv construct.
Another approach would be to better integrate the Application and
program_options. E.g. the Application could be initialized with an
options object and a container object to hold the parsed options. Then
the main() method (or, what I'd prefer the call operator) would simply
get the already parsed parameters.
Of course there is also the option to extend program_options so that it
can parse not only from argc and argv, but from a range of string like
objects. Then you could use begin() and end() to create a range from the
vector< string >, you could use argv and argv[argc], or any other
kind of range. That might also be usefull for situations where
application is not used.
Personally I'd prefer the last option, because it opens up new
possibilities for other situations as well and keeps application
flexible as well. Integrating program_options in application would take
away the liberty from the user to not use program_options for whatever
reasons. The idea with init() is clumsy and passing argc and argv to the
constructor is just like passing them to the main method itsself.
-- okunah gmbh Software nach MaÃ Werner-Haas-Str. 8 www.okunah.de 86153 Augsburg cd_at_[hidden] Registergericht Augsburg GeschÃ¤ftsfÃ¼hrer Augsburg HRB 21896 Christof Donat UStID: DE 248 815 055
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk