TApplication and command line arguments

Dear ROOT experts

I have observed a funny behavior and I don’t get why ROOT behaves like this:
Basically I’m using a ROOT application compiled with g++ with some command line arguments called by

./Fluka TT TTaU Hit_TTaU_r75.root 2634

The main method of ./Fluka creates any instance of TApplication

TApplication theApp("Analysis", &argc, argv);

Now after this line argc drops from 5 to 4 and the parameter Hit_TTaU_r75.root vanishes from argv.
I can recover the old parameters by

argc = theApp.Argc();
argv = theApp.Argv();

but it seems to me quite fishy. First of all, I don’t understand why exactly this argument vanishes from argv and the others stay.

Many thanks and best regards,


The TApplication object will consume all the parameter that it knowns about (-b, root files, etc.). The root files passed as argument can be retrieved from TApplication::InputFiles.


Hi Philippe,

thanks a lot for the explanation although I have to admit that I do not like this kind of “I-know-what-you-want-to-do” behavior of TApplication as it messes with position of the remaining arguments within argv.

Cheers, Chris

Try: [code]#include “TApplication.h”

int main(int argc, char **argv)
int itmp = (argc > 1 ? 1 : argc);
TApplication theApp(“Analysis”, &itmp, argv);
// …
return 0;

Hi Pepe

No, this does definitely not solve it. But as I said, the easiest way is to recover them from the TApplication. I was just wondering what causes this behavior.
So I think we can close this discussion.

I’m pretty much sure that my solution works. Just try “./Fluka -?” or “./Fluka -h” without my fix.
Without my fix, you may be able to “recover” parameters that were “consumed” by the TApplication, but they may have already changed the behaviour of that object (i.e. of your whole application).

Hi Pepe

Of course your fix works from the point of view of recovering the arguments, but you also hide them to the TApplication which is not always desirable. You can also make just a copy of the two variables solving also the problem.
I do not think that we need to discuss this any further as Philippe has already mentioned the point about the “fishy” behavior I was interested in.

Cheers, Christian