[ANN] CLI command line interface compiler for C++
Hi, I am pleased to announce the first public release of CLI. CLI is an open-source (MIT license), cross-platform command line interface compiler for C++. It allows you to specify the options that your program supports, their types, and default values. For example: include <string>; class options { bool --help; std::string --name = "example"; unsigned int --level | -l = 5; }; This specification can then be automatically translated to C++ classes that implement parsing of the command line arguments and provide a convenient and type-safe interface for accessing the extracted data. For example: #include <string> class options { public: options (int argc, char** argv); options (int argc, char** argv, int& end); bool help () const; const std::string& name () const; unsigned int level () const; ... }; int main (int argc, char* argv[]) { options o (argc, argv); if (o.help ()) print_usage (); if (o.level () > 4) cerr << "name is " << o.name () << endl; ... } It is easy to start using CLI in your application since there are no external dependencies. You can compile your command line interface to C++ and simply add the generated files to your project's source code. For a five minute introduction to CLI, see the "Hello World" example in the CLI Getting Started Guide: http://www.codesynthesis.com/projects/cli/doc/guide/#2 More information, documentation, and source code distributions are available from the project's web page: http://www.codesynthesis.com/projects/cli/ Enjoy, Boris -- Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog Open-source XML data binding for C++: http://codesynthesis.com/products/xsd XML data binding for embedded systems: http://codesynthesis.com/products/xsde
Boris Kolpackov wrote:
Hi,
I am pleased to announce the first public release of CLI.
Are you proposing this for inclusion in Boost, or are you just advertising? If it's the former, how does your library compare against program_options, already part of Boost? --Jeffrey Bosboom
Hi Jeffrey, Jeffrey Bosboom <jbosboom@uci.edu> writes:
Are you proposing this for inclusion in Boost
I think it is too early to think about this since it is just the first public release. Also, as you have mentioned, there is the program_options library already in Boost which tries to address the same problem though in a different way.
If it's the former, how does your library compare against program_options, already part of Boost?
I have answered this question in detail in the following two blog posts: http://www.codesynthesis.com/~boris/blog/2009/06/28/cli-cxx-the-ideal-soluti... http://www.codesynthesis.com/~boris/blog/2009/07/05/cli-cxx-existing-solutio... In a nutshell, program_options has the following main drawbacks: - verbosity - the use of strings to identify options (easy to misspell) - the need to specify the option type every time its value is retrieved (lack of type safety) CLI addresses these problems by using a concise, special-purpose language to capture the option specifications and by using functions with static return types to access the option values. Boris -- Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog Open-source XML data binding for C++: http://codesynthesis.com/products/xsd XML data binding for embedded systems: http://codesynthesis.com/products/xsde
Hello, looks interesting. is there an easy way to pass arguments to an underlying framework, e.g. Qt's QCoreApplication like -display, -font etc?, even it is not a valid option to the program self, which shall expect the classic form of long/short option e.g. --debug|-d ??? Is it possible to write (as it can be done for boost.program_options) for gcc compiler's "-frtti" and -fno-rtti" without blowing up the DSL cli file? Maybe generating the usage() from the DSL cli file with grouping of options like as it can be done by using boost.program_options? Thanks, Olaf
Hi Olaf, Olaf Peter <ope-devel@gmx.de> writes:
looks interesting. is there an easy way to pass arguments to an underlying framework, e.g. Qt's QCoreApplication like -display, -font etc?, even it is not a valid option to the program self, which shall expect the classic form of long/short option e.g. --debug|-d ???
Yes, there are several ways to do this. I don't know if QCoreApplication does this, but normally a subsystem like this would have a chance to parse the argc/argv array first and remove all the options from argv that are specific to it. As a result, your application doesn't see any of the Qt options. But even if QCoreApplication doesn't do this, you can instruct the CLI-generated classes to ignore unknown options.
Is it possible to write (as it can be done for boost.program_options) for gcc compiler's "-frtti" and -fno-rtti" without blowing up the DSL cli file?
There is no support for this at the moment though it can probably be implemented. Something like this: class options { std::vector<std::string> -f*; std::vector<std::string> -fno-*; }; I've added this to the potential feature list to think about.
Maybe generating the usage() from the DSL cli file with grouping of options like as it can be done by using boost.program_options?
Yes, providing options documentation in the .cli file and then generating the usage information, man pages, etc. is on the TODO list for the next version. Boris -- Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog Open-source XML data binding for C++: http://codesynthesis.com/products/xsd XML data binding for embedded systems: http://codesynthesis.com/products/xsde
I am pleased to announce the first public release of CLI.
CLI is an open-source (MIT license), cross-platform command line interface compiler for C++. It allows you to specify the options that your program supports, their types, and default values. For example:
include <string>;
class options { bool --help; std::string --name = "example"; unsigned int --level | -l = 5; };
This specification can then be automatically translated to C++ classes that implement parsing of the command line arguments and provide a convenient and type-safe interface for accessing the extracted data. For example:
#include <string>
class options { public: options (int argc, char** argv); options (int argc, char** argv, int& end);
bool help () const; const std::string& name () const; unsigned int level () const;
... };
int main (int argc, char* argv[]) { options o (argc, argv);
if (o.help ()) print_usage ();
if (o.level () > 4) cerr << "name is " << o.name () << endl; ... }
It is easy to start using CLI in your application since there are no external dependencies. You can compile your command line interface to C++ and simply add the generated files to your project's source code.
For a five minute introduction to CLI, see the "Hello World" example in the CLI Getting Started Guide:
http://www.codesynthesis.com/projects/cli/doc/guide/#2
More information, documentation, and source code distributions are available from the project's web page:
What's the benefit of your solution if compared to Boost.ProgramOptions? Does it generate code based on the Boost.ProgramOptions API? Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com
Hi Hartmut, "Hartmut Kaiser" <hartmut.kaiser@gmail.com> writes:
Does it generate code based on the Boost.ProgramOptions API?
No, because the CLI compiler knows the options at compile-time, it can produce a much simpler implementation. Plus, using ProgramOptions would introduce an external dependency which I tried to avoid. Right now all one needs is the generated code. Boris -- Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog Open-source XML data binding for C++: http://codesynthesis.com/products/xsd XML data binding for embedded systems: http://codesynthesis.com/products/xsde
participants (4)
-
Boris Kolpackov -
Hartmut Kaiser -
Jeffrey Bosboom -
Olaf Peter