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

[A100]

fxsaber:

Смысл в возможности передать по ссылке.

Также как и со строками у Разработчиков есть возможность (если уже не сделали) итак все передавать по ссылке без фактического копирования переменной

void f()
{
        MqlTick tick;
        SymbolInfoTick( NULL, tick );
        g( tick );
}

inline void SymbolInfoTick( string symbol, MqlTick& tick )
{
      tick = _LastTick; //ленивое программирование: а не будем ничего копировать,
                        //пока _LastTick не изменится
}

И это будет решение не для одной конкретной структуры MqlTick, а на все случаи жизни

[Ilyas]

A100:

Что лишний раз подтверждает, что никакого смысла в использовании напрямую _Digits, _Point, _Period, _LastError и т.д. нет (и даже _Symbol можно заменить на NULL). Фактически они должны быть объявлены как const volatile

А Вы наоборот - предлагаете дополнить этот ряд

Вы правы, но только они почтиvolatile, кроме флага IsStopped - он volatile на 100%, т.е. любое чтение IsStopped, это 100% чтение памяти.
Для остальных, почтиvolatile - значит, что компилятор МОЖЕТ закешировать значение переменной в регистре при первом обращении и при следующем обращении к такой переменной использовать закешированное значение, но только в пределах одной функции или ветки вызовов, если они заинлайнились в одну функцию.
Это можно (и нужно), так как смена предопределённых переменных (кроме IsStopped) не может произойти внутри MQL точки входа  (OnXXX функции)

По поводу МОДИФИКАТОРА ПЕРЕМЕННОЙconst, скажем так, что используeтся const программистами для программистов.
Как мы знаем, через приведение можно сменить константность епеременной, поэтому компилятору нельзя доверять модификатору const.
Если компилятор видит, что переменная не меняла значения и инициализируется константой, то он и без модификатора const превратит такую переменную в непосредственное значение (ImmediateValue)

По поводу _LastTick, мы обсуждаем, но...
Это структура, а не простой-атомарный тип и изменяться она может внезапно, в любой точке MQL программы, в том числе и во время получения значения.
Получается, что для адресации к этой структуре нужно вводить синхронизатор.

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

[Igor Makanu]

Ilyas:

По поводу _LastTick, мы обсуждаем, но... 

Это структура, а не простой-атомарный тип и изменяться она может внезапно, в любой точке MQL программы, в том числе и во время получения значения.
Получается, что для адресации к этой структуре нужно вводить синхронизатор.

но в тестере _LastTick не может измениться в любой точке MQL программы ?

если да, то дайте такое решение только для тестера, где скорость расчетов наиболее важна

[Alexey Navoykov]

Igor Makanu:

но в тестере _LastTick не может измениться в любой точке MQL программы ?

если да, то дайте такое решение только для тестера, где скорость расчетов наиболее важна

Так а что мешает один раз запросить этот тик в обработчике OnTick, и дальше уже работать с полученным данными?  Это практически ничего не стоит.  Зачем по 100 раз запрашивать его (как в приведённых ранее тестах), искусственно создавая тормоза на ровном месте.  Т.е. проблему кривого кода советника предлагается решать усложнением внутренней работы МТ.   Или у вас есть какие-то нормальные замеры?

[fxsaber]

Alexey Navoykov:
Так а что мешает один раз запросить этот тик в обработчике OnTick, и дальше уже работать с полученным данными?

Мешает низкая квалификация создателей советников, которыми грузят Маркет и Облако.

[Maxim Kuznetsov]

Alexey Navoykov:
Так а что мешает один раз запросить этот тик в обработчике OnTick, и дальше уже работать с полученным данными?  Это практически ничего не стоит.  Зачем по 100 раз запрашивать его (как в приведённых ранее тестах), искусственно создавая тормоза на ровном месте.  Т.е. проблему кривого кода советника предлагается решать усложнением внутренней работы МТ.   Или у вас есть какие-то нормальные замеры?

события которые должен обработать "OnTick" поступают извне в некоторую очередь с приоритетами. В прочих обработчиках не лишне убедится, что подобных новых событий не прилетало, иначе данные прежнего тика невалидны/устарели

[Igor Makanu]

Alexey Navoykov:
Так а что мешает один раз запросить этот тик в обработчике OnTick, и дальше уже работать с полученным данными?  Это практически ничего не стоит.  Зачем по 100 раз запрашивать его (как в приведённых ранее тестах), искусственно создавая тормоза на ровном месте. 

я именно так и делаю в тестере

Alexey Navoykov:
 Т.е. проблему кривого кода советника предлагается решать усложнением внутренней работы МТ.   Или у вас есть какие-то нормальные замеры?

ну как бы кривость кода определяется устоявшимися приемами написания кода, посмотрите КБ и использование СБ в этих примерах

я не использую СБ, я замерял профилировщиком и искал решения несколько месяцев, был топик про тесты скорости, частично бросал альтернативные решения

нормальность замера? это скользкая тема, которой придется заниматься серьезно, меня устраивает мой ЕА для оптимизации, был проход на 18 месяцев 6 сек, сейчас 2,5 сек , имхо я проделал хорошую работу над собой )))

[A100]

По материалам ... возникли следующие соображения:

Учитывая, что UninitializeReason() может вызываться в любой части программы, в частности в OnInit() (а если не предполагался такой вызов, то можно и расширить границы применения)

Предлагается:

Если значение переменной _UninitReason формируется перед вызовом функции OnDeinit(),

и если причина предыдущей деинициализации эксперта не может быть определена (REASON_PROGRAM, REASON_REMOVE, и т.д.)

то до этого вызова оно должно быть неопределено (-1). Сейчас 0, т.е. фактически REASON_PROGRAM

Если эксперт полностью перезапускается (REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE и т.д.), то

представляется, что есть возможность при запуске новой копии программы установить переменной _UninitReason соответствующее значение (REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE и т.д.),

а не как сейчас 0, т.е. фактически REASON_PROGRAM

Если эксперт частично перезапускается (REASON_CHARTCHANGE и т.д.), то переменная _UninitReason и сейчас в OnInit() равна соответствующему значению (REASON_CHARTCHANGE и т.д.),

и никаких изменений не требуется

[Sergey Dzyublik]

Баг  МТ5 (build 2450) ошибка компиляции для форвард декларации шаблонного метода класса.

template<typename T>
class A{};


class B{
public:
   template<typename T>
   void test(A<T> &a);
};

template<typename T>
void B::test(A<T> &a){}   // 'test' - member function already defined with different parameters 


void OnStart(){ 
   B b;
} 

[Artyom Trishkin]

При перезапуске терминала постоянно и безостановочно пишет в журнал записи

2020.05.24 03:36:03.342 HistoryBase     'GBPUSD' 1 invalid bars removed

Время исторического бара в записи постоянно увеличивается. График GBPUSD Daily открыт и дёргается - нулевой, первый и второй бары удаляются/создаются. И так по кругу.

Вот жду. То ли забьёт весь SSD этими логами, то ли остановится наконец...

Вчерашний лог в прицепе.