Fix parser

Fixes #445 (closed).

I am using a new variable in the parameter structure (is_default) that I set to 1 if we write in params a default value.

Currently I am only checking on the get_opt_params function. I am wondering if we should ensure that we are not reading a mandatory parameter from a default value.

For example:

parser_get_opt_param_double(params, "Test:test", 1.); // Test:test does not exist in params
parser_get_param_double(params, "Test:test"); // Here currently we read the previous default value without any warning

Any suggestion @pdraper, @matthieu?

Can you explain what the code is now doing?

If we are reading a parameter and then reading it a second one with a different default value, do we get the second default on the second read?

So now we can ask for the same parameter multiple times as long as we provide the same default value. If Test:test1 does not exists:

/* This one pass and write in parser the parameter */
double a = parser_get_opt_param_double(parser, "Test:test1", 1.);

/* This one pass and return the default value 1. which is the same than in the previous call */
a = parser_get_opt_param_double(parser, "Test:test1", 1.);

/* This one fails because the previous default value is not the same */
a = parser_get_opt_param_double(parser, "Test:test1", 0.);

For the non optional parameters, the behavior is still the same. If we consider that Test:test2 does not exist:

/* Here we fails because Test:test2 does not exists */
double a = parser_get_param_double(parser, "Test:test2");

/* This one pass and write in parser the default value 1. */
a = parser_get_opt_param_double(parser, "Test:test2", 1.);

/* Now this one pass because the previous line add the parameter to parser */
a = parser_get_param_double(parser, "Test:test2");

My question now is what should we do in the second case? Should we fail the last line or not? I think that both solutions can be accepted. If we accept it, it means that we do not have to update all the calls when changing a default value and we consider that the developer knows the call order. If we refuse it, it means that we do not accept changes in the type (mandatory/optional) of a parameter.

Ok, but that was already the case in the previous version. The problem we had arises when you read the same parameter with different defaults.

Look at the last line in the first example. This is the case that you are talking about and now an error is raised

Ok, sorry, I misspoke. So this solution makes it illegal to read a parameter twice with different default values. We'll have to make some changes to other code then.

Yes we will need, but I think it is the cleanest way to do it.

It should only be G that should be changed, right?

Let me think about how to what we want in the cleanest way.

Ok, just to write down what we talked about earlier: let's throw error messages for anything that is not the obvious expected behaviour. So reading the same value twice, with and without default should return an error code.

Is this now ready for inspection?

added 1 commit

• 52429330 - Check if parameters are read only once

Compare with previous version

added 1 commit

• 0bc2f487 - undo a change

Compare with previous version

Sorry I forgot to push it. Yes it is ready now

Thanks for the update!.

@pdraper was there anything more from last week's discussion that you think should be done here?

assigned to @matthieu

changed the description

added 2 commits

• 2f19f5a8 - Initialise the minimal temperature correctly.
• 50ffd5ec - Change short int to int

Compare with previous version

resolved all discussions

Thanks!