Denis Shevchenko wrote:
Christoph Heindl wrote:
Hi Denis
How does your library compare to Boost.Program_options [1]?
-- Christoph
[1] http://www.boost.org/doc/libs/1_42_0/doc/html/program_options.html
Hi, Christoph!
I now about Boost.Program_options, and use it in my programs some time. But later I decide create my own solution, because Boost.Program_options have some limitation.
First, it cannot call functions/functors. If I put in command line some parameter, I want some reaction on it. In my lib reaction occure immediately, in parsing process (but after all correction checks). Lib know nothing about this reaction's semantic, it just call correspond boost::signal.
Oh? Surely there's typed_value::notifier that allows to specify callbacks.
Second, it cannot check "value semantic" of parameters. If parameter's value must be a valid path (or valid IPv4, or some else), I may want to check it immediately, in parsing process. In this case, my lib checks value's validity (using Boost.Filesystem, or my own algorithms) and, if error occurs, generate correspond std::exception.
It it unclear to me why you insist on doing such checks during the parsing. ProgramOptions performns such checking when parsed tokens are stored in variables_map, which seems like a sensible separation of responsibilities to me. - Volodya