Handle command line options in a separate PonoOptions class #51
Conversation
options/options.h
Outdated
| PonoResult parse_and_set_options (int argc, char ** argv); | ||
|
|
||
| // Pono options | ||
| Engine engine; |
There was a problem hiding this comment.
we use the convention to append _ at the end of every data member.
There was a problem hiding this comment.
though, we are not clear if we would use this convention for private members only
|
clang-format |
utils/ponoresult.h
Outdated
|
|
||
| typedef enum | ||
| { | ||
| PROPERTY_TRUE = 0, |
There was a problem hiding this comment.
It definitely makes sense to avoid magic constants, but I'm wondering if we should just unify this and ProverResult instead of having two separate classes: https://github.com/upscale-project/pono/blob/e25fb8fa112eeb2b85427fda9475d9b247994654/core/proverresult.h#L25
options/options.cpp
Outdated
|
|
||
| namespace pono { | ||
|
|
||
| bool PonoOptions::instance_created = false; |
There was a problem hiding this comment.
This is global, right? Does this mean there's only one PonoOptions object allowed? We don't have to do this now, but it might actually be nice to allow multiple option configurations in memory. In IC3IA for example, options are a struct that's passed to the prover and it accesses the different options from there. Then, you can have programs that run provers with different options.
| class PonoOptions | ||
| { | ||
|
|
||
| // TODO: for now, all class members (i.e., Pono options) are public |
There was a problem hiding this comment.
We could also just make this a struct. For this kind of object, I'm not opposed to keeping everything public. What are your thoughts @lonsing and @ahmed-irfan?
There was a problem hiding this comment.
on a second thought, maybe class would be more clean and safe.
|
Thanks for you feedback, @makaimann and @ahmed-irfan! I addressed your comments in my changes:
|
engines/bmc.h
Outdated
| { | ||
| public: | ||
| Bmc(const Property & p, smt::SmtSolver & solver); | ||
| Bmc(PonoOptions & opt, const Property & p, smt::SmtSolver & solver); |
There was a problem hiding this comment.
maybe the options object reference be const
engines/prover.h
Outdated
| { | ||
| public: | ||
| Prover(const Property & p, smt::SmtSolver & s); | ||
| Prover(PonoOptions & opt, const Property & p, smt::SmtSolver & s); |
There was a problem hiding this comment.
const PonoOptions &opt
There was a problem hiding this comment.
Looks good to me! I just left one minor comment. IMO after that and addressing @ahmed-irfan's comments, this is ready to merge.
| PonoOptions pono_options; | ||
| ProverResult res = pono_options.parse_and_set_options(argc, argv); | ||
| if (res == ERROR) return res; | ||
| assert(res == pono::UNKNOWN); |
There was a problem hiding this comment.
Could you add one comment before this assert just clarifying that it should be unknown if the options are all set and error otherwise?
|
Thanks, @makaimann and @ahmed-irfan, I included your suggested changes. Please let me know whether you are fine with merging this. |
…-centaur#51) * handle cmd-line options in separate class * clang-format * pass PonoOptions object to Prover object * fixed options default initialization * unify ProverResult and PonoResult (removing the latter class) * clang-format * passing 'const PonoOptions &', adding comment
Changes in this PR:
mainfunction inpono.cppto a new classPonoOptions. The purpose of this change is to simplify the main function and make option handling more extensible (e.g. as future work, we might want to set options via calls of an API). Also, with this change, options can be accessed from any class by referencing a globalPonoOptionsobject. As for theLoggerobject, exactly onePonoOptionsobject exists.enum PonoResultrepresenting the return value of themainfunction inpono.cpp(formerly calledint status_code) to avoid the use of magic constants.