print() feature request

[peterritter]

Hi
Here is some unsolicited feeback.

In general, when one is developing, it is always convenient to be able to print out the state of an object. I think you should have a simple parser::print(std::ostream&) function which prints all option name:value pairs as well as all non-options arguments in a nicely formated, easy to read way. You can never go wrong with a feature like that.

Also, for printing the help, I don't really like the syntax you have have chosen:

std::cout << parser << std::endl;

I think a parser::print_help(std::ostream&) member has better semantics. From the above syntax it is unclear just what exactly is being printed.

Thanks, Peter

[Fytch]

Hi

it is always convenient to be able to print out the state of an object

Indeed, that would be a helpful feature. I was thinking about printing the parser in the JSON format? That way it is readable by humans as well as machines, which is nice. What do you think?

I don't really like the syntax you have have chosen: std::cout << parser << std::endl;

I'm kind of undecided regarding this. On one hand, Stream << Object is very common syntax in C++, on the other hand, I agree that the output format is unclear. I have to think about it.

Cheers

[peterritter]

hi

well, to be more clear you could do something like:

std::cout << parser.help_info() << std::endl;

JSON isn't that easy to read for humans. You'd have to 'pretty print' JSON, at which point I'm not sure it is still legal JSON. I think being able to get the data as json would be a good thing. But having a nicely formated print for humans is also imortant. Program options don't need a multilevel tree structure. Program options are primarily structured like a .ini file. A .ini file is very easy for people to read and write and an additional idea would be for your class to read arguments from an .ini file rather than being limited to just the command line.

In my current project I am working on a computational problem that requires programs to be lauched thousands or even millions of times with varying arguments. Arguments can be passed as name=value pairs on the command line or via an .ini file containing name=value pairs. The command line is of course a little faster since it avoids having to write an .ini file first. But in some cases being able to use a .ini file is great because they are easy to edit. This could be a way to extend the library's functionality. I'm thinking less of predeclared named options with type, but more where you accept any number of name=value pairs and you analyze the value (maybe using regex) to see what type it has. Essentially analyzing 'unnamed parameters' for name=value content, rather than just retaining the raw string. I think there is room to make the traditional program options parsing much more useful for other applications.
I don't know how much work you want to put into this library? Is this a school project for you? or some other learning exercise?
Regards, Peter

[Fytch]

I agree, the output format should be clearer. I'll try out some things next week.

You'd have to 'pretty print' JSON, at which point I'm not sure it is still legal JSON.

There's JSON that's both pretty and legal. Consider the following:

{
    "optimization": 3,
    "files": [ "foo.cxx", "bar.cxx" ]
}

I find this very readable. Furthermore, JSON is extremely wide-spread so parsing it at a later stage should be no problem for any programming language.

In my current project I am working on a computational problem that requires programs to be lauched thousands or even millions of times with varying arguments.

Have you considered making the program's API available via a shared library? That would eliminate any interface overhead.

I don't know how much work you want to put into this library? Is this a school project for you? or some other learning exercise?

It's just a small personal library that I use in my other project because it is comfortable and single-header. I decided to share it because why not?
Sure, I'm willing to invest time into this library. There's definitely some things that can be improved, especially the unsafe union stuff in struct value and its clunky type system. I also greatly appreciate your feedback and try to implement it as good as possible. Who knows, maybe the user base will even grow one day?
However, I don't know if ini-File parsing is in the scope of this library. There's other difficulties attached to that, e.g. sections or Unicode.

Regards, Josua

PS: are you German by any chance?

[peterritter]

Hi
I'm Austrian. Originally from near Lake Constance ( Bodensee). But I left Austria around 1982. I only go back for skiing occasionally. I live in England now, near London. How about yourself?

Peter

[peterritter]

hi
This is my current project :

http://www.tradingsystemapi.com/

This is a very outdated web site, but it should give you an idea.
P.

[mrzv]

It would be nice to be able to print only the options, without the usage. I prefer to write my own usage line that's more informative than the default, and also provide a brief description of what the program does, but it is really nice to be able to output the options straight from the parser.

It would also be nice if the options order in the output followed the order in which they were defined (so more important options could be shown first, for example).

[Fytch]

I think it would be best to offer const iterators in parser so that the programmer can freely view all options (in the order added) and build his own output function on top of these iterators. There is actually a branch for that (https://github.com/Fytch/ProgramOptions.hxx/commits/feature/iterate-options) but it's out of date now. I'd need to rewrite it so that the iterators obey the order of insertion. But this concept offers the maximum amount of flexibility and freedom.

On top of that, I could implement simple helper functions (as @peterritter suggested), e.g. one that print name:value pairs or another that prints the parser's state in JSON.

As for order perservation: that's a really obvious point and so I immediately implemented it: cd56dbd