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

Новый комментарий
 

Функция 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 метод/поле  или применил :: - на компилятор не надейся

 
Igor Makanu:

спорить не буду

решил все таки описать проблему которую обсуждаем, кстати поведение MQL все больше на поведение C# стало похожим, код не скомпилировался

//+------------------------------------------------------------------+
class A
{
private:
   int               count;
public:
                     A():count(0) {}
   static void       inc()        { count++; }

};

A a;
//+------------------------------------------------------------------+
void OnStart()
{
   a.inc(); //code generation error 
   A::inc();
   
}
//_______________________________________________________________________

вот обьвил метод inc() - он работает с защищенным полем

если я добавил модификатор статик - где должен компилятор прекратить проверку?  - я же принял решение что мне нужна точка входа в обьект за пределами видимости? 

 
Igor Makanu:

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

Баги случаются. Пишу код, как и раньше: this, ::, const, static, private, public, protected ставится везде, где это только можно.

Мне это нужно в первую очередь для быстрого понимания своего кода. Во вторую - чтобы компилятор помогал во время написания. А он, действительно, хорошо помогает.


Вчера столкнулся первый раз с такой ситуацией. Написал код на 5Кб, часть из которого было копи-пастой из разных работ. И при первой же компиляции не оказалось ни одной ошибки или предупреждения. Удивился.

 
Igor Makanu:

решил все таки описать проблему которую обсуждаем

//+------------------------------------------------------------------+
class A
{
private:
   int               count;
public:
                     A():count(0) {}
   static void       inc()        { count++; } // Здесь ошибка, о которой компилятор сейчас не сообщает.

};
[Удален]  
Igor Makanu:

решил все таки описать проблему которую обсуждаем, кстати поведение MQL все больше на поведение C# стало похожим, код не скомпилировался

вот обьвил метод inc() - он работает с защищенным полем

если я добавил модификатор статик - где должен компилятор прекратить проверку?  - я же принял решение что мне нужна точка входа в обьект за пределами видимости? 

У Вас переменная count не статическая.

Как статическая функция узнает, какому объекту эта переменная принадлежит?

1...255725582559256025612562256325642565256625672568256925702571...3768
Новый комментарий