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

 

Волшебная строка

#include "key.mqh"
virtual int f( const ABCDEFGHIJK ) const { return ABCDEFGHIJK; }

Последовательность действий (строгая)

  1. Поместить прилагаемые файлы в одну папку. Далее мышью в MetaEditor  
  2. Файл->Открыть->выбрать Test.mqh->кнопка Открыть
  3. Правка->Поиск и замена->Заменить->заполнить поля Найти: и 'Заменить на:' как показано ниже->кнопка 'Заменить все'

Результат: 

Настройки здесь: https://www.mql5.com/ru/forum/1111/page1127#comment_795376 

Файлы:
Test.mqh  1 kb
key.mqh  1 kb
 
Alexey Kozitsyn:
Да, не Вам одному помощь нужна здесь. Я вот несколько недель пытаюсь тики закатать нормально в свечу. Так что... тики еще сыроваты. Заявка в СД #1598238
Тики нормально закатываются в свечу.
[Удален]  
fxsaber:
Тики нормально закатываются в свечу.
Серьезно? И объемы совпадают? И Вы контроль делали? И даже логи можете показать?
 
Alexey Kozitsyn:
Серьезно? И объемы совпадают? И Вы контроль делали? И даже логи можете показать?

Контроль делал - смотреть кодобазу. На несовпадение объемов свечей и вычисленных - плевать, т.к. там идет речь о граничном тике, который может попасть либо в один бар, либо в другой. И это не принципиально. Индикатор торгового оборота также выкладывал на форуме. Так что никаких проблем.

 

В Вашем случае, если очень сильно занудствовать, можно придираться к механизму создания баров, но не к CopyTicks. 

 

 Ошибка при компиляции

class A {
protected:
        void f(  int ) {} //(*)
};
class B : public A {
public:
        void f( uint ) {}
};
void OnStart()
{
        B b;
        b.f( 1 ); //'A::f' - cannot call protected member function
}

А если убрать строку (*), то все нормально. А чем B::f(uint) не устроила?. Если рассмотреть ситуацию с другой стороны

class A {
public:
        void f(  int ) {} //(**)
};
class B : public A {
public:
        void f( uint ) {}
};

то проявляются фундаментальные недостатки MQL алгоритма поиска подходящей функции. Во 2-ом примере пока нет строки (**) - будет вызываться B::f(uint). Как только появится строка (**), то будет вызываться  A::f(int). А значит изменения в базовом классе влияют на конечный результат - в то время как в С++ всегда будет вызываться B::f(uint) независимо от изменений в базовом классе, что гарантирует стабильность конечного результата.

В MQL получается, что разработчик класса A придумал всего лишь новую public\protected\private функцию, а из-за этого у пользователя класса B перестал компилироваться код и/или что более критично - изменился конечный результат

 
A100:

Волшебная строка

#include "key.mqh"
virtual int f( const ABCDEFGHIJK ) const { return ABCDEFGHIJK; }

Последовательность действий (строгая)

  1. Поместить прилагаемые файлы в одну папку. Далее мышью в MetaEditor  
  2. Файл->Открыть->выбрать Test.mqh->кнопка Открыть
  3. Правка->Поиск и замена->Заменить->заполнить поля Найти: и 'Заменить на:' как показано ниже->кнопка 'Заменить все'

Результат: 

Настройки здесь: https://www.mql5.com/ru/forum/1111/page1127#comment_795376 

Спасибо за сообщение, ошибка будет исправлена в следующем обновлении.
 
A100:

 Ошибка при компиляции

class A {
protected:
        void f(  int ) {} //(*)
};
class B : public A {
public:
        void f( uint ) {}
};
void OnStart()
{
        B b;
        b.f( 1 ); //'A::f' - cannot call protected member function
}

А если убрать строку (*), то все нормально. А чем B::f(uint) не устроила?. Если рассмотреть ситуацию с другой стороны

class A {
public:
        void f(  int ) {} //(**)
};
class B : public A {
public:
        void f( uint ) {}
};

то проявляются фундаментальные недостатки MQL алгоритма поиска подходящей функции. Во 2-ом примере пока нет строки (**) - будет вызываться B::f(uint). Как только появится строка (**), то будет вызываться  A::f(int). А значит изменения в базовом классе влияют на конечный результат - в то время как в С++ всегда будет вызываться B::f(uint) независимо от изменений в базовом классе, что гарантирует стабильность конечного результата.

В MQL получается, что разработчик класса A придумал всего лишь новую public\protected\private функцию, а из-за этого у пользователя класса B перестал компилироваться код и/или что более критично - изменился конечный результат

Просто константа "1" в вызове b.f( 1 ) интерпретируется как int. Сделайте явное приведение, и всё заработает:

b.f( (uint)1 ); 

[Удален]  
fxsaber:

В Вашем случае, если очень сильно занудствовать, можно придираться к механизму создания баров, но не к CopyTicks. 

Не согласен с Вами, т.к. ошибки по логам, продемонстрированным мной в ветке про тестирование CopyTicks(), говорят об обратном. Да и... о чем Вы вообще!? Мы тут что, какие-то предположения создаем, типа "попадет/не попадет"? Вы же сами несколькими постами выше жаловались на проблему!? А какая разница тогда? Ну подумаешь там какие-то миллисекунды, ну и что, что один тик другой обогнал, какая разница!?
[Удален]  
fxsaber:
Однако, Ваш пост натолкнул меня на одну мысль. Возможно, проблемы с тиками у нас с Вами, не такие уж и разные...
 
Alexey Kozitsyn:
Не согласен с Вами, т.к. ошибки по логам, продемонстрированным мной в ветке про тестирование CopyTicks(), говорят об обратном
К сожалению, не понимаю проблемы по логам, когда нет кода.