Ошибки, баги, вопросы - страница 2564

 
Igor Makanu:

?

странная ситуация, со стаитиками давно работает все вне класса. а я тут распинаюсь.... ради прикола воспроизведите у себя код:

Вы видите экземпляр объекта? ... а он есть в MQL ;)

ЗЫ: причем есть на уровне справки... ко мне какие претензии?  

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

pr


imp

 
Andrey Barinov:

К статикам применимы все те же правила (private, protected, public), просто они не требуют создания объекта.

В общем случае нет: например публичный статик нельзя ограничить в производном классе

 
Andrey Barinov:



хм... как бы обьяснить абсурдность ситуации... Вы чего меня квотите в очередной раз? я предложил Вам ознакомиться с сообщениями админов (разработчиков), я показал справку которую они написали, Вы от меня чего хотите своими картинками? 

я не размышляю почему оно так, читаю форум и справку и делаю как рекомендуют разработчики. Считаете нужным ну напишите в "комитет по защите стандартов С++", в ООН... ну хотя бы админу в ЛС, если слабо, но тогда заквотьте сообщения разработчиков и добейтесь своего! 

ЗЫ: у меня как то получается вставлять исходники, а не картинки, почему у вас так не получилось?

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

ЗЫ: ситуация довольно комичная, хотел помочь,, теперь оправдываюсь.... на кой? - ну бейте в рельсу добивайтесь правды...наступайте на грабли.... 
 
Igor Makanu:

В коде ошибка только в доступе к private-методу. Этот баг появился недавно.

 

Функция ChartOpen всегда возращает 0 в сервисе. Хотя сам график открывает. 

#property service

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

  // return(INIT_SUCCEEDED);
  }
 
fxsaber:

В коде ошибка только в доступе к private-методу. Этот баг появился недавно.

думал я что то забыл, вот перечитал как в C# статики себя ведут https://metanit.com/sharp/tutorial/3.6.php

Статические члены класса являются общими для всех объектов этого класса, поэтому к ним надо обращаться по имени класса:

Следует учитывать, что статические методы могут обращаться только к статическим членам класса. Обращаться к нестатическим методам, полям, свойствам внутри статического метода мы не можем.


а в MQL статики инициализируются до запуска OnInit() , теперь обсуждаем глобальную видимость приват методов у статиков.... ну такое поведение статиков в MQL - если используем статики, значит не пользуемся возможностями защиты данных в классе, имхо

и насколько это баг? - да как повернут разработчики так и будет, я же пишу, что поведение при использовании операции контекста определяет программист ( оператор разрешения контекста — является оператором с самым высоким приоритетом в языке! ), а насколько компилятор сумеет правильно помочь ну как получится )))

вот так  работает?

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        
  }

 в целом задачи выполняет


PS: обновился на 2145 - код со статиками ведет себя так же, ну если в таком виде побудет с полгода, окажется что это запланированное поведение статиков    ;)

UPD: вспомнл как на сленге это все называется - грязные приемы! ))) - поискать их много примеров в сети, где то это поведение как стандарт языка воспринимается, а где то привязано к конкретным компиляторам от производителя. В Питоне же eval() по сути полностью рушит линейное выполнение кода? - ну кто то юзает, кто то пишет не юзать, т.к. поведение непредсказуемое


UPD: проверил на 2145 свой вопрос заданный месяц назад  https://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)
  {
  }
//_______________________________________________________________________

ничего не изменилось, на bool при проверке типов компилятор так не научился писать предупреждения - вот это вот очень не приятно, уже искал у себя ошибку в коде, хотя была уверенность, что компилятор MQL всегда строго следит за соответствием типов

 
Igor Makanu:

и насколько это баг? - да как повернут разработчики так и будет

Очевидно же, что баг исправят.

ничего не изменилось, на bool при проверке типов компилятор так не научился писать предупреждения

Автоматический кастинг указателей и числовых типов  в bool - это очень удобно.

 
Igor Makanu:

ничего не изменилось, на bool при проверке типов компилятор так не научился писать предупреждения - вот это вот очень не приятно, уже искал у себя ошибку в коде, хотя была уверенность, что компилятор MQL всегда строго следит за соответствием типов

При данном кастинге нет потери данных. Либо 0, либо не 0.

Другое дело, когда имеет место кастинг double -> любой целочисленный тип (до int32 включительно)

 
Slava:

При данном кастинге нет потери данных. Либо 0, либо не 0.

Другое дело, когда имеет место кастинг double -> любой целочисленный тип (до int32 включительно)

а наоборот? 

я искал у себя баг уже в коде

сначала написал тест, но использовал сначала int , потом отказался в сторону bool, но исправил не весь код, уже не помню, но примерно так:

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

}

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

}
//_______________________________________________________________________


я к такому поведению как бы готов сейчас, но почему пишу об этом...ну в проверке условий MQL в if() - жестко типы контролирует? любое использование не булевых операций выдает же предупреждение? - ну и как писал в том же C# в VS2017 - мой код примера не будет скомпилирован, а MQL не выдает предупреждений. По моему для новичков в программировании под MQL такое поведение таит некие сюрпризы.

 
fxsaber:

Очевидно же, что баг исправят.

спорить не буду, но свое мнение, что закладываться на контроль от компилятора при выходе за пределы класса через статики как и использование оператора разрешения контекста - не стоит ,

т.е. если написал static метод/поле  или применил :: - на компилятор не надейся

Причина обращения: