Goodbye robot - hello marasmus - page 7

New comment
 
Renat:
...

Testing of this example:

  • MQL4/MQL5 - gives warnings on potential errors

  • Visual Studio 2012, including Code Analysis - nothing, the quality of analysis for potential errors is zero. They don't bother since there's no competitors for a long time.

  • PVS Studio - reports correctly.

  • Lint - reports the same thing, but the 'x' hide...

    ...

Pavlick:

I think the messages are absolutely useless too. I'm not a professional programmer, but this kind of nonsense in µl stresses me. I wonder if references to a and b are constant, will PVS Studio generate a warning (no way to check it myself)?

Still, it's not a bad thing to get to the bottom of the warning first and then cite it as an argument. PVS Studio will warn you not because the global variable is hidden, but because a and b are passed by a non-constant reference but are not modified. In that case, they believe that a and b should be passed by a constant reference. For instance, the following examples do not make this analyzer complain:

int a=1,b=2;
int sum(const int& a, const int& b){
        return(a+b);
}

int main(){
        return sum(a,b);
}

//-------------------------------------------------
int a=1,b=2;
int sum(int& a, int& b){
        ++a; ++b;
        return(a+b);
}

int main(){
        return sum(a,b);
}
 

I'm well aware of what PVS is blaming us for.

Once again, we don't have the burden of responsibility to compile billions of lines of old C/C++ code. It is up to their own compilers not to spoil their business by generating warnings. We, on the other hand, have the responsibility for security and error control of our application language, which works with money.

Only few percent of MQL4/5 code authors are professional (in the true sense of the word) programmers. All the rest are just self-taught and have no idea how badly they write code.

For example, after the migration to the updated MQL4, we had to manually plow through thousands of sources in the kodobase and fix an incredible number of errors in their old code. A lot of errors have been found and shown by the compiler, even without running the programs.

That is why we should not make claims about issuing warnings but fix our own code.

 
Renat:

I'm well aware of what PVS is blaming us for.

Once again, we don't have the burden of responsibility to compile billions of lines of old C/C++ code. It is up to their own compilers not to spoil their business by generating warnings. We, on the other hand, have the responsibility for security and error control of our application language, which works with money.

Only few percent of MQL4/5 code authors are professional (in the true sense of the word) programmers. All the rest are just self-taught and have no idea how badly they write code.

For example, after the migration to the updated MQL4, we had to manually plow through thousands of sources in the kodobase and fix an incredible number of errors in their old code. A lot of errors have been found and shown by the compiler, even without running the programs.

That's why you should not complain about issuing warnings, but fix your code.


If the array allows you to miss its range, it would be very silly to take efforts comparable to those of writing the indicator when writing the indicator itself, but only for the calculation of the calculation start.

You don't have to dig through this code, half of it is not fixed, it's broken. You could have just made an additional property to distinguish between old mql4, new mql4 or new mql4 with strict. What size does the old compiler take? I don't know, but probably less than a megabyte, no problem to lug it around in the era of gigabytes. But here we have a kind of heroic deed - destruction of codebase.

* * *

Warning

Declaration of 'a' hides global declaration at line X

This is an idiotic warning. If somebody out there in the "higher" world has problems with it, it doesn't mean that others might have such problems. There's a scope to variables, what someone calls variables is a private matter.

 
Integer:


If an array is allowed to slip past its range, it would be very silly when writing the indicator to make efforts comparable to those of writing the indicator itself, but only to calculate the starting point of the calculation.

You could have avoided digging through this code, half of it is not fixed but broken. Could have just made an extra property to distinguish between old mql4, new or new with strict. What size does the old compiler take? I don't know, but probably less than a megabyte, no problem to lug it around in the era of gigabytes. But here's a kind of heroic work done - to destroy the codebase.

Exactly fixed, not broken.

If an error slipped in after edits, it's entirely possible - any editing inevitably leads to such errors. But that doesn't mean that you can hang single errors on a flag and climb a mountain of corrected ones.


The 'a' hides global declaration at line X

This is an idiotic warning. If someone in the "higher" world has problems with it, it doesn't mean that others may have such problems. There is an area of variable visibility, what anyone calls variables is a private matter.

Amazing people fighting for the right to self-shoot. It's especially gratifying that a person writes "leave the old compiler alone" in all seriousness.
 
simpleton:

A potential error is a potential error because it is not necessarily an error at all.

I don't know, I don't know. We used to have a rule of thumb to put level 4 or 5 warrants on release and check the box to count warrants as errors.

We got rid of really stupid warnings with pragmas, but we still got rid of them.

 
Andrei01:

This remark is meaningless and does not provide any useful information to the programmer in principle, because there is no concealment of the variable "a", as claimed.

1.cpp(3): remark #3280: declaration hides variable "a" (declared at line 1)
  int sum(int& a, int& b){       

If the programmer deliberately uses hiding, then yes, this remark is meaningless and does not provide any useful information. If, on the other hand, the concealment was accidentally done through negligence, the remark allows us to detect the error at an early stage.

Andrei01:

Hiding occurs only when a local copy of the variable is created, which is also a perfectly legitimate action. Even if an error suddenly occurs in the code because of this hiding, it is easily found precisely because the search immediately finds the same name. If we start to change and alter the names in a function template, which is a "solution" to this rule by compiler logic, the error search situation will become much more complicated and confusion will abound in understanding the code. It seems obvious.

Local variables and parameters are in one scope, so it does not matter if a parameter has this name or a local variable, but in any case this name hides a name in the outer scope.

Hiding has nothing to do with copies of variables, it has to do with entity names. Yes, even though it's related to entity names such as types:

class A { };

void f(int a) {
        A x;
}

it compiles:

$ icpc -c 1.cpp
$

And this:

class A { };

void f(int A) {
        A x;
}

It doesn't:

$ icpc -c 1.cpp
1.cpp(4): error: expected a ";"
        A x;
          ^

compilation aborted for 1.cpp (code 2)
$

Because the name A inside a function is no longer a type name, but a variable-parameter name. The name of the type declared in the outer scope is now hidden by the name of the variable-parameter. You can get an indirect glimpse of this by finding out that this code

class A { };

void f(int A) {
        A++;
}

compiles well:

$ icpc -c 1.cpp
$

In MQL4++ this does not compile already at the stage of hiding type name by variable-parameter name, i.e. even with an empty function body:

#property strict

class A { };
void f(int A) { }
void OnStart() { }

result:

'A' - structure identifier cannot be used       3.mq4   4       12
'A' - structure identifier cannot be used       3.mq4   4       12

I don't know why, but I'm not surprised at all.

For C++, on the other hand, there is no problem with such code:

class A { };
void f(int A) { }

result of a compilation attempt:

$ icpc -c 1.cpp
$

This example shows that the hiding is related to entity names and not to anything else.

If the remark is not switchable, we have to invent all sorts of things, like aliasing. But if it is turnable, as in Intel compiler, you don't have such problems.

The problem in MQL4++ is not with the compiler functionality itself concerning the detection of hiding names in nested scopes but with the fundamental inoperability of this functionality.

 
Renat:

So one should not make claims about the warnings, but fix one's own code.

The complaint about the warnings/remarks under discussion, I think, can be one - about their in principle non-excludability.

And, of course, you cannot tell the programmer what to do within the language and what not to do.

 

Such messages (hiding global variables) just don't make sense in C++ (mql was declared as c++ like, right?). For example, here's why:

struct S1{
    int val;
};

struct S2{};

template<typename _T>
struct SS : _T{
    int f() {int val; return val;}
};

int main(){
    SS<S1> q1; q1.f();
    SS<S2> q2; q2.f();
}
 
Pavlick:

Such messages (hiding global variables) just don't make sense in C++ (mql was declared as c++ like, right?). For example, here's why:

struct S1{
    int val;
};

struct S2{};

template<typename _T>
struct SS : _T{
    int f() {int val; return val;}
};

int main(){
    SS<S1> q1; q1.f();
    SS<S2> q2; q2.f();
}

C++ was taken here because MQL4++ has no structure/class templates - only function templates?

I'm not sure if developers are aware of that, but class templates are also possible in MQL4++, though with significant limitations. In particular, this example can be transposed to MQL4++ in the following way (also a parameter is used instead of a local variable in a method):

#property strict

struct S1 { };
struct S2 { int val; };

template <typename T>
void f(T &t) {
  struct SS: public T {
    int f(int val) { return val; }
  } ss = {0}; // Переменная типа SS
}

void OnStart() {
  S1 s1; f(s1);
  S2 s2; f(s2);
}

A single warning about hiding the name will be popped up at compilation:

'3.mq4' 3.mq4   1       1
struct has no members, size assigned to 1 byte  3.mq4   3       8
struct has no members, size assigned to 1 byte  3.mq4   8       10
declaration of 'val' hides member declaration at line 4 3.mq4   9       15
0 error(s), 3 warning(s)                1       4

If the last significant line in OnStart() is commented out, the warning about hiding the name disappears.

 
simpleton:

C++ was taken here because there are no structure/class templates in MQL4++ - only function templates?

...

Generally, yes, but you can also use µl:

struct S1{
    int val;
};

struct S2{};

#define INSTANTIATE(_Name, _T)          \
    struct _Name : _T                   \
    {                                   \
        int f() {int val; return val;}; \
    }

INSTANTIATE(SS1, S1);
INSTANTIATE(SS2, S2);

void start(){
    SS1 q1; q1.f();
    SS2 q2; q2.f();
}
1234567891011121314...16
New comment