Menu ▾ ▴

#27 Static 'disable_rest' is global for all Cmdline objects to come

1.2.x
closed-duplicate
None
5
2020-10-02
2020-10-02
Frank
No

I'm using TCLAP within a SystemC simulation to handover arguments to methods of sc_modules from a script that controlls the simulation. So I have not one main function that makes use of command line parsing just once, but I have many sc_modules that do command line parsing over and over again. I use 'CmdLine::parse(std::vector<std::string> &args)' for that.</std::string>

After the first use of the static function (which is the use of '--disable_rest') no further parsing of arguments for future CmdLine objects is possible since '--disable_rest' remains active forever after. As a quick solution I added another method I called 'endIgnoring()' and made it part of the destructor ~Arg.

This solves this for most of it but unfortunately not completely. SystemC as a simulation environment for simulated parallel execution. So a module which called '--disable_rest' and disabled argument parsing for all could then 'sc_wait' and the simulator schedules another module. As the first modules ~Arg destructor was not called yet, the second parallel module cannot function correctly.

Each object of the Commandline class should have its own 'bool _ign'

Discussion

  • Daniel Aarno

    Daniel Aarno - 2020-10-02

    Interesting to hear that you are using TCLAP with SystemC, I was actually part of the SystemC Working Group some years ago :)

    I think this specific problem should have been fixed in 1.4 [2a4ae2], so you could give that a try.

    As for the other variables, this is a bad design choise from many years ago that may be difficult to resolve in a good way without significant API change (see https://sourceforge.net/p/tclap/bugs/25/ for some context). So you may run into similar situations depending on your use.

     

    Related

    Commit: [2a4ae2]

  • Daniel Aarno

    Daniel Aarno - 2020-10-02
    • status: open --> closed-duplicate
    • assigned_to: Daniel Aarno
     
  • Frank

    Frank - 2020-10-02

    So you know my former work collegue Philipp A. Hartmann then? :-)

     

Log in to post a comment.