Errors, bugs, questions - page 2564

New comment
 
Igor Makanu:

?

it's a strange situation, everything outside the class has been working for a long time with the staichiqs. and i'm just making a big fuss about it.... Just for fun, reproduce the code yourself:

Do you see an object instance? and it exists in MQL ;)

SZZ: And it exists at help level ... what's your beef with me?

https://www.mql5.com/ru/docs/basis/oop/staticmembers

pr


imp

 
Andrey Barinov:

All the same rules apply to statics (private, protected, public), they just don't require object creation.

Not in general: for example, a public statik cannot be restricted in a derived class

 
Andrey Barinov:



hmmm... How to explain the absurdity of the situation... I suggested you read the posts by the admins (developers), I showed you the help they wrote, what do you want from me with your pictures?

I do not think why it is so, I read the forum and help, and do as recommended by the developers. If you think it's necessary, write to "committee on protection of C++ standards", to UN... Well, at least the administrator in the PM, if that's not enough, but then lock up the developers messages and get your way!

ZSY: I somehow manage to insert source code and not pictures, why didn't yours do so?

int print(int value)
{  Print(value,":",__FUNCTION__); 
 return(value);
}
class A
{
private:
   static int        a1;
   static void       inc_a1(){a1++; Print("a1 = ", a1);}
protected:
   static int        a2;
public:
   static int        a3;

};
//+------------------------------------------------------------------+
static int A::a1 = print(1);
static int A::a2 = print(2);
static int A::a3 = print(3);

//+------------------------------------------------------------------+
void OnStart()
{

A::inc_a1();
A::inc_a1();
A::inc_a1();

}

2019.09.17 22:11:49.534 tst (EURUSD,H1) 1:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) 2:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) 3:print

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 2

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 3

2019.09.17 22:11:49.535 tst (EURUSD,H1) a1 = 4

ZS: the situation is quite comical, I wanted to help, now I'm making excuses.... why? - well, hit the rail for the truth...step on the rake....
 
Igor Makanu:

The only bug in the code is in the private-method access. This bug has appeared recently.

 

The ChartOpen function always returns 0 in the service. Although the chart itself opens.

#property service

//int OnInit()
void OnStart()
  {
   long Otvet= ChartOpen(Symbol(),PERIOD_D1);
   Print("Otvet=",Otvet);

  // return(INIT_SUCCEEDED);
  }
 
fxsaber:

The only bug in the code is in the private-method access. This bug appeared recently.

I thought I forgot something, so I re-read how statics behave in C#https://metanit.com/sharp/tutorial/3.6.php

Static class members are common for all objects of the class, therefore you must refer to them by their class name:

Note that static methods can only refer to static class members. We can't address non-static methods, fields, properties inside a static method.


In MQL, statics are initialized before running OnInit() , now let's discuss the global visibility of private methods for statics.... this behavior of statics in MQL - if you use statics, it means we don't use data protection features of a class, imho

how big a bug is it? - the way developers will do it, I said that behavior in context operations is determined by programmer (context resolution operator is the operator with the highest priority in the language! ), and the compiler will help correctly - well, as it happens)))

does it work like this?

class A
  {
private:
   static void              My_function()
     {
      Print("^_^");
     }
  };
  
A a;
void OnStart()
  {
   A::My_function();
   a.My_function();  // 'A::My_function' - cannot access private member function        
  }

on the whole, it does the job


PS: updated to 2145 - code with statics behaves the same, if it will stay like this for half year, it will turn out that this is the planned behavior of statics ;)

UPD: remember, as slang for all this is called - dirty tricks! ))) - Look for a lot of examples on the web, where this behavior is accepted as a language standard, and where it is tied to a specific compiler from the manufacturer. In Python, isn't eval() effectively breaking linear code execution? - well, some do and some don't because the behavior is unpredictable.


UPD: check on 2145 my question from a month agohttps://www.mql5.com/ru/forum/320733#comment_12989063

https://www.mql5.com/ru/forum/320733#comment_12958594

void OnStart()
  {
   double x=100.0;
   f(x);
  }
//_______________________________________________________________________
void f(bool v)
  {
  }
//_______________________________________________________________________

nothing has changed, on a bool type check the compiler has not learnt to write warnings - this is very unpleasant, I was looking for an error in my code, although I was sure that the MQL compiler always checks for type matching

 
Igor Makanu:

How much of a bug is it? - Whatever the developers turn it around, that's how it's gonna be.

It's obvious that the bug will be fixed.

Nothing has changed, the compiler has not learned how to write warnings on bool when checking types

Automatic casting of pointers and numeric types to bool is very convenient.

 
Igor Makanu:

nothing has changed, on bool when checking types the compiler has not learned to write warnings - this is very unpleasant, I was already looking for an error in my code, although I was sure that MQL compiler always strictly monitors type matching

There is no data loss during this casting. Either 0 or not 0.

Another case is when double -> any integer type (up to and including int32)

 
Slava:

With this casting, there is no data loss. Either 0 or not 0.

Another thing is when casting double -> any integer type (up to and including int32)

but the other way round?

I was looking for a bug in my code

At first I wrote a test, but used first int , then I gave up using bool, but I did not fix the whole code, I do not remember, but it was like this:

void OnStart()
{  int x=100.0;
   f(x); }
//_______________________________________________________________________
void f(int  v)  //так тестил
{
   if(v>0) v++;

}

//_______________________________________________________________________
void f(bool  v)  // потом решил, что мне нужен флаг, а ниже забыл исправить код
{
   if(v>0) v++;

}
//_______________________________________________________________________


I'm kind of ready for such behavior now, but why am I writing about it...well, in checking MQL conditions in if() - does it strictly control types? any use of non-boolean operations will issue a warning? - And in the same way I wrote in C# in VS2017 - my example code won't compile and MQL won't throw a warning. In my opinion, for those who are new to programming in MQL, such behavior implies some surprises.

 
fxsaber:

It is obvious that the bug will be fixed.

I will not argue, but my opinion is that you should not rely on control from the compiler when you leave the class via statics as well as using context resolution operator,

i.e. if you write a static method/field or use ::: - do not rely on the compiler

1...255725582559256025612562256325642565256625672568256925702571...3190
New comment