Goodbye robot - hello marasmus - page 8

New comment
 
simpleton:

Local variables and parameters are in the same scope, so - it doesn't matter if a parameter has this name or a local variable, but either way this name hides the name in the outer scope.

Not in any case. When passing a variable by reference, no local copy is created and work is done directly with the passed variable. So what kind of hiding is going on here?
 
Andrei01:
Not in any function. When a variable is passed by reference, a local copy is not created and operation is performed directly with the passed variable. So what kind of hiding is going on here?

This is where the hiding of names takes place. Everything else - copy, not copy - is secondary. Inside a function, when a reference name is used, the work will be done on the object the reference refers to. If it refers to an object in the outer scope, the work will be done with it. This is not because there is no name-hiding - the hiding is present, just as in other cases - but because the reference points to this object. A function is called this way. Passed on this very object by reference and it now points to it. When calling and passing at the moment of calling another object, the same function code will work with another object.

I was giving an example with a type name and a variable name, i.e. with entities that are as different in nature as possible, to show that hiding applies/references to names, and everything else is secondary.

However, when trying to create another example in MQL4++ on this theme, I accidentally discovered that an additional scope is created for parameters in MQL4++. The scope of local variables is already nested in it:

#property strict

void f(int a) {
  int saved = a;
  int a = a + 1;

  Print("saved = " , saved, ", a = ", a);
}

void OnStart() {
  f(3);
}

This example is COMPILED with a characteristic warning:

declaration of 'a' hides local declaration at line 3    3.mq4   5       7

And later it is successfully executed:

23:52:22 Script 3 EURUSDm,H1: loaded successfully
23:52:22 3 EURUSDm,H1: initialized
23:52:22 3 EURUSDm,H1: saved = 3, a = 4
23:52:22 3 EURUSDm,H1: uninit reason 0
23:52:22 Script 3 EURUSDm,H1: removed

It's obvious that another "layer" scope is created for parameters in MQL4++. This is why it is possible to declare a local variable with the same name as the parameter.

In C/C++ there is no such "layer":

void f(int a) {
  int saved = a;
  int a = a + 1;
}

The compiler explains popularly that there is already a variable with that name in the scope:

$ icpc -c 1.cpp
1.cpp(3): error: "a" has already been declared in the current scope
    int a = a + 1;
        ^

That is, the scope of function parameters and its local variables are one and the same.

Why it's not so in MQL4++ and for what purpose it's not - is, of course, an interesting question...

 
simpleton:

void f(int a)

This example COMPILES with a characteristic warning:

This case discusses the case of passing a variable by reference and an erroneous warning, not the creation of a local copy.

void f(int& a)
 

I only read the first few posts.

Of course, things don't go quite smoothly under the mat either. There are some lapses of the developers here in testing the product that reaches the end user. However, also MT4 is not strong in multi-currency strategies (testing), and needs, needs to be refined. So I hope it will be someday, after all.

If you do not know how to program, do not go to the real one, and use the demo for now. As always a bad dancer gets in the way of "balls", including gold and pink.

Good luck!


 
Andrei01:

This is a case of passing a variable by reference and an erroneous warning, not creating a local copy.

void f(int& a)

It doesn't really matter in terms of the nature of the warning. Moreover, it doesn't matter not only if a variable is passed by reference or by value, but what type it is:

#property strict

int a; // line 3
class A { };
void f(A *&a) { } // line 5
void OnStart() { }

The code compiles, the warning you're discussing is generated:

declaration of 'a' hides global declaration at line 3   3.mq4   5       12

For some reason you don't want to understand that.

The warning itself is not at all erroneous. Moreover, at a quick glance, scope tracking in MQL4++ is surprisingly well done compared to how other things are done.

Warnings, while true, are not practical, and yet you can't turn them off - that's what it's all about. And by no means the transmission of the link.

 
simpleton:

In terms of the nature of the warning, this is irrelevant. Furthermore, it does not matter whether the variable is passed by reference or by value

There is a large difference in the essence of the warning between passing the variable itself and modifying it in a function and creating a copy of it, while the variable itself remains unchanged.

And the fact that the warnings can not be disabled or customized, it's a classic MC proprietary style - "do not let":))) There's nothing you can do about it, but you can only humbly and meekly accept it because this style has been elevated to the status of a religious attribute... There is no point in searching for logic or any kind of justice here. ))

 

Ugh ugh I have all the methaquot stuff working like clockwork.

No complaints at all.

 
simpleton:

A potential error is just that, a potential error is not necessarily an error at all. Therefore, the statement that "it means we have to fix these errors" is wrong, because they may NOT be errors at all.

...

These people are geeks. Such dorks fight the compiler like a windmill not understanding the main thing: the compiler is your ally! Rejoice when the compiler swears at potentially unsafe code fragments. Rejoice even if the application crashes right after launch with an error string. But God forbid that you get an unmanageable code when there are no errors or warnings and the program seems to work well but every now and then strange glitches occur whose cause cannot be tracked anywhere. At such moments you get covered with vapor and start dreaming about errors like"invalid pointer" or "division by zero".
 
C-4:
But God forbid that you get an unmanageable code when there are no errors or warnings and the program seems to work well but strange bugs occur now and then, the reason for which cannot be found anywhere. At such moments you get covered with vapor and start dreaming about errors like "invalid pointer" or "division by zero".

The compiler has nothing to do with it, it is typical buggy programming when there are no test checks in dangerous code fragments where undefined or erroneous states are possible, that's why the glitches appear.

Functional code checks have nothing to do with the compiler and there is no point in expecting that from the beginning.

Again professional programmers usually don't look at the warnings because they know the compiler's logic while compilers are useless in checking code functionality.

 
Andrei01:

There is a big difference in essence warnings between passing the variable itself and modifying it in a function and making a copy of it, while the variable itself remains unchanged.

Here it's just a different type of warning. About hiding names.

The variable itself is not passed. A reference to it is passed.

12345678910111213141516
New comment