MikeMirzayanov's blog

By MikeMirzayanov, 5 years ago, translation, In English

Hello!

It seems to me that over the past few years I have been writing something right while all normal people are celebrating the New Year. It's my tradition now! Actually, most of the core functionality of Codeforces was written on the New Year holidays of 2010: authorization, blogs, basic support for competitions.

Perhaps I want to spend the next year with interest improving something in the Codeforces infrastructure (yep, how you celebrate the New Year — so you will spend it). Or maybe it's just that it's not necessary to work on New Year's and I'm doing not what you need right now, but what would be nice to do someday.

This time I took a little time to add support for parsing command line parameters in testlib. I really don't like to write such lines of code int n = atoi(argv[3]); in generators. Actually for several reasons:

  • it is unsafe that the 3rd command line parameter may be absent;
  • It is unsafe that the 3rd command line parameter may not be a valid 32-bit integer.

Now, instead, you should write this: int n = opt<int>(3);. In addition, you can write like this int64_t m = opt<int64_t>(1); or bool t = opt<bool>(2); or even string s = opt(4);.

In addition, I supported named parameters. If there are too many parameters, then the entry g 10 20000 a true is less readable than g -n10 -m200000 -t=a -increment.

In this case, now you can use the following code snippets in your generator:

int n = opt<int>("n");
long long n = opt<long long>("m");
string t = opt("t");
bool increment = opt<bool>("increment");

You can freely mix parameter reading by index and by name.

The following options for writing named parameters are supported:

  • --key = value or-key = value;
  • --key value or-key value — if value is not a start of a new parameter (does not start with a hyphen or does not follow the letter after one/two hyphens);
  • --k12345 or-k12345 — if the key k is one letter and then a digit comes;
  • -prop or--prop — to enable boolean properties.

Below are examples of how to run several fictional generators:

g1 -n1
g2 --len=4 --s=oops
g3 -inc -shuffle -n=5
g4 --length 5 --total 21 -ord

Perhaps in a hurry, I can write something not in the best way, or even with bugs. I suggest you look at my last commits. I will be glad to suggestions or fixes.

Thanks for attention.

What traditions do you have for the New Year?

  • Vote: I like it
  • +468
  • Vote: I do not like it

»
5 years ago, # |
  Vote: I like it +40 Vote: I do not like it

auto n = opt<int>(3)?

»
5 years ago, # |
  Vote: I like it -16 Vote: I do not like it

What traditions do you have for the New Year?

Every New Year as proud Hrvat me and my comrades partake in rare art of "shitpost" which mblazev teach to me.

  • »
    »
    5 years ago, # ^ |
      Vote: I like it +8 Vote: I do not like it

    It's not even funny anymore... If it ever was.

»
5 years ago, # |
  Vote: I like it +24 Vote: I do not like it

We have a tradition of serving Malpua (A deep-fried pancake). "Mal-" means goods. "-Pua" means Pancake. It has Dry fruits with optional mashed banana fried in clarified butter. It's a lip-smacking experience for any feast. Hope the next contest on codeforces is as tasty as that :) HNY2020

»
5 years ago, # |
Rev. 4   Vote: I like it +7 Vote: I do not like it

When i try to use opt in my generator i get this compile error when uploading it to polygon:

More information: the following code causes the same error:

#include "testlib.h"
#include <iostream>

int main(int argc, char* argv[])
{
    registerGen(argc, argv, 1);
    int n=opt<int>("n");
    cout<<n<<endl;
}

I tried ticking the Auto-Update box next to testlib.h but the same error appears.

UPD: I'm able to compile it now.

»
5 years ago, # |
  Vote: I like it 0 Vote: I do not like it

Ok, now i seem to be able to put opts in my generator in polygon without a compile error, but one thing the blog doesn't mention is how to make a boolean variable false. I assumed that since the blog says that for example -increment makes opt<bool>("increment") true that simply not putting anything related to increment to command line would make opt<bool>("increment") false, but instead it gives an error FAIL Opts: unknown key 'keyname'. Something like -keyname=false works, but is there a better way?

»
5 years ago, # |
Rev. 2   Vote: I like it +30 Vote: I do not like it

Could you support options which receive default values when they are missing in the command line?

  • »
    »
    5 years ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    I also request this, I don't like writing if (__testlib_opts.count("arg")) {} else {}

»
4 years ago, # |
  Vote: I like it +10 Vote: I do not like it

Having used this feature extensively, there is one thing that regularly confuses me. If you write int n = opt<int>("n"); but do not provide n in the command line, the error message is something like "unknown key: 'n'". To me, this suggests the exact opposite situation: that the key is in the command line arguments but not in the program (even though this doesn't make sense in this case). Could we change the wording here?