Is there any interest in command line interpreter class templates?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Is there any interest in command line interpreter class templates?

alexey.tsoy
Hello everybody,

The file command_line.zip in the containers directory in Boost’s vault contain command line interpreter library. There you can find simple tutorial with examples and draft documentation.

The library supports variable amount of option parameters as well as automatic type casting. Note that their types may be diferent.

The library doesn't require special linking because it contains headers only. You only need to type in a few lines of code to start using it.


Regards
Alexey
Reply | Threaded
Open this post in threaded view
|

Re: Is there any interest in command line interpreter class templates?

Joel falcou-4
How does it compare to program_options in term of features, test and new
enabled use cases ?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Is there any interest in command line interpreter class templates?

Joshua Boyce-2
In reply to this post by alexey.tsoy
One of the primary reasons that I (and others) avoid Boost.ProgramOptions is
that it doesn't 'natively' support wide strings (wide strings are simply
static_cast to narrow strings with no regard to localization or
internationalization). How does this library compare in that respect?
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Is there any interest in command line interpreter class templates?

alexey.tsoy
      | One of the primary reasons that I (and others) avoid Boost.ProgramOptions is
      | that it doesn't 'natively' support wide strings (wide strings are simply
      | static_cast to narrow strings with no regard to localization or
      | internationalization). How does this library compare in that respect?

  This library was developed with taking an account of variable string types.
Here is explanation how it is dealt with wide strings below.
The class interpreter<CharType, .. > has invoke() function template.

Executing the function 
  
              interpreter<CharType,..>::invoke(option_name, args_iterator_begin, args_iterator_end)

cause to calling appropriate handler like below
 
              option_handler
              (
                  type_cast <first_argument_type> (* (args_iterator_begin++))
                , type_cast <second_argument_type> (* (args_iterator_begin++))
                ...
              );

With this you can be sure that during intervening calls, 
the data will not be changed. 

Also in the class there is a template function "visit". By passing your
'visitor' into the function you can get information about all registered options,
their alternative names and description. 
Display the information based on internationalization settings.

One more moment that may be will have to reconsider it is parser
which is present in library. I have tested it to wstring, however, it can
not be working in some situations. But in any case, you have the ability
use your own parser.
 

  | How does it compare to program_options in term of features, test and new
  | Enabled use cases?

To the features can be attributed automatically detecting parameters of 
an option(on the basis of the signature handler).
That allows us to develop more reliable code.
Auto-tests of multiple base classes are available.

Thank you very much for your interest.

Regards,
Alexey

P.S. please give my apologies for long reply due to my poor English.
Reply | Threaded
Open this post in threaded view
|

Re: Is there any interest in command line interpreter class templates?

Stirling Westrup
In reply to this post by Joshua Boyce-2
On Mon, Jun 20, 2011 at 10:02 PM, Joshua Boyce
<[hidden email]> wrote:
> One of the primary reasons that I (and others) avoid Boost.ProgramOptions is
> that it doesn't 'natively' support wide strings (wide strings are simply
> static_cast to narrow strings with no regard to localization or
> internationalization). How does this library compare in that respect?

Another reason for avoiding Boost.ProgramOptions is that it doesn't
support command lines that interleave options and arguments, where the
ordering of options and arguments is important. How does this library
handle such cases?


--
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Is there any interest in command line interpreter class templates?

alexey.tsoy

The function command_line::invoke_all calls the appropriate handlers in the order that they appear in the command line.

      i.e. command_line:: invoke_all (..., "-option_2 -option_1");

      Firstly, the handler of the option_2 will be executed, and then the handler of the option_1 will be executed.


The order of the option arguments corresponds to their order in the handler signature.


Regards,
Alexey

Reply | Threaded
Open this post in threaded view
|

Re: Is there any interest in command line interpreter class templates?

alexey.tsoy
In reply to this post by alexey.tsoy
The boost/vault storage was removed in a few days after this library had been presented.

Now, you can download it from the following link : http://sourceforge.net/projects/interpreter11/files/latest/download

Best regards,
Alexey