Need getArgs() accessor to Util::Application to retrieve start-up arguments about poco HOT 6 CLOSED

What's wrong with Application::options() ?

from poco.

Not sure I understand. I want the value of argv[] that was passed to main()... even if it's converted into a std::vectorstd::string instead.

options() doesn't provide this.

from poco.

I want the value of argv[] that was passed to main()

Use Application::config():

config().getInt("application.argc");
config().getString("application.argv[n]");

from poco.

That's what I do, but I'm suggesting that if (a) we didn't blow away _args in processOptions() and (b) provided a const accessor to it, that might be a lot simpler.

What happens if the internal organization of the code changes and instead of being keyed as "application.argc" it gets keyed by some other name?

There's a setArgs() method. Good object design suggests that a corresponding getter-method would be appropriate.

from poco.

That's what I do, but I'm suggesting that if (a) we didn't blow away _args in processOptions() and (b) provided a const accessor to it, that might be a lot simpler.

After initialization, the _args vector only contains parameters that were not processed by processOptions(). Changing semantics to leave _args vector intact after processing options would break existing code that relies on it.

What happens if the internal organization of the code changes and instead of being keyed as "application.argc" it gets keyed by some other name?

One could ask the same question for anything, including the above description of how code would break if we do what is asked for here. We break existing code only if we decide that benefits outweigh the pain incurred. I do not foresee "aplication.argc" to change unless ANSI C and existing widespread code naming conventions suddenly change.

There's a setArgs() method. Good object design suggests that a corresponding getter-method would be appropriate.

setArgs() is private so getArgs() availability does not follow from its existence.

The only option is to have another vector that retains all arguments but that won't happen in 1.5.1. There is an easy, reasonable and consistent workaround for what you are trying to achieve.

from poco.

added in develop for 1.5.1:

7e8797f

from poco.