Errors, bugs, questions - page 2890

New comment
 
Roman:

If you need to catch an error of this value, well initialise it with 333 ))
It's only a start value.

That's right, it's a bug. So either we give a warning on assigning uninitialized variables in all cases, or we don't, and initialize it with default zero for example, within the language in all the same cases.

 
Valeriy Yastremskiy:

That's right, it's a bug. It turns out that either we give a warning to assign uninitiated variables in all cases, or then we don't give it, but initiate it with default zero for example, within the language in all the same cases.

Only where in the above examples did you see such cases?

 
A100:

Only where in the above examples did you see such cases?

Forum on trading, automated trading systems and strategy testing

Bugs, bugs, questions

A100, 2020.10.27 16:11

You have to initialize it, but only with a meaningful value. There is no such value in the above example, so the practice is not bad, the only possible one. Otherwise there would be double initialization

int f( int i ) { /*вычисления*/ }
void g( int k )
{
        for ( int i = 0, j; i < k; i = j )
        {
                j = f( i );
                /*вычисления*/
        }
}

 
Roman:

And where isthe assignment of uninitialised variables? Which variable is uninitialised? and to whom is it being assigned? What you highlighted: j from = to the left j=, not to the right =j, i.e. it is not assigned to anyone before it is itself assigned a value

 
A100:

Only where in the above examples did you see such cases?

Yes, slipped my mind, in all cases the uninitialized variable has an assignment, not the other way around. Perhaps the compiler goes top-down in a line-by-line fashion, in which case yes, assignment is at the bottom and vice versa at the top. There's also a warning about possible assignment to a non-initialized variable.

 
A100:

And where isthe assignment of uninitialised variables? Which variable is uninitialised? And to whom is it being assigned? What you have highlighted is j=, not =j

Assignment to an uninitialized variable, in the loop body. Before the first iteration j is not initialized yet.
It will be initialized after the first iteration is passed.
The loop body is executed first, and then the incremental scope. Which you have replaced by i = j

 
Roman:

Assigning to an uninitialized variable, in the function body. Before the first iteration j is not yet initialized.
It will be initialized after the first iteration.
The function body is executed first, and then the increment area. Which you have replaced with i = j

Nope, that's right, not inferring j on the first iteration is initiated just j=f(i) and on the second it will only be i=j I think the compiler is parsing from top to bottom and giving warnings.

 
Valeriy Yastremskiy:

No, that's right, the variable j is not initialized on the first iteration just j=f(i) and on the second iteration only i=j I think the compiler parses from top to bottom and gives warnings.

Yes, but before the first iteration the j variable is not yet initialized, this is what the compiler is swearing at.

 
Valeriy Yastremskiy:

Yes, I was wrong, in all cases of uninitialized variable there is an assignment, not the other way around. Maybe the compiler goes top-down, so yes, assignment is at the bottom and vice versa at the top. There's also a warning about possible assignment to a non-initialized variable.

This may be when the compiler has no information objectively:

void f( int& i ) { /*вычисления*/ }
void OnStart()
{
        int i;
        f( i );
        int j = i; //нормально ??? а если i не инициализирована?
        printf("%d",j);
}

i.e. maybe f() was initializing i and maybe not. And here the C++ compiler gives a warning, while the MQL one somehow does not.

 
A100:

This may be when the compiler objectively has no information:

i.e. maybe f() had i initialization, maybe not. And here C++ compiler gives a warning, MQL doesn't.

I can't know what they say. i think a simpler compiler. Parses the layout syntax from top to bottom for obvious syntax errors, not respecting types and using wrong variables. When in the second example the initialization was put down, it didn't generate a warning. Although the execution of the program is identical.

1...288328842885288628872888288928902891289228932894289528962897...3190
New comment