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
— ifvalue
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 keyk
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?
auto n = opt<int>(3)
?Every New Year as proud Hrvat me and my comrades partake in rare art of "shitpost" which mblazev teach to me.
It's not even funny anymore... If it ever was.
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
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:
I tried ticking the Auto-Update box next to testlib.h but the same error appears.
UPD: I'm able to compile it now.
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
makesopt<bool>("increment")
true that simply not putting anything related to increment to command line would makeopt<bool>("increment")
false, but instead it gives an errorFAIL Opts: unknown key 'keyname'
. Something like-keyname=false
works, but is there a better way?Could you support options which receive default values when they are missing in the command line?
I also request this, I don't like writing
if (__testlib_opts.count("arg")) {} else {}
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?