Новая версия платформы MetaTrader 5 build 5200: расширение OpenBLAS и усиление контроля в MQL5 - страница 5

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

с констаностью переменной придётся расстаться

Могут быть ситуации, когда такое ограничение не даст компилятору создать оптимальный код?

 
fxsaber #:

Могут быть ситуации, когда такое ограничение не даст компилятору создать оптимальный код?

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

 
Ilyas #:
Из аналогичных измненений в скором будущем - это запрет на вызов оператора = по наследованию, пример:

Ээээ... А как же наследование и перегрузка функций? 

Или это касается только оператора присваивания? 

Иногда очень удобно, когда в объект добавляется новая функциональность - остальные функции продолжают работать, как у старого объекта! 

А тут, получается, в приведённом коде - объект уже нельзя присвоить, надо вписывать новую функцию присвоения, которая, фактически, ничего не будет делать, кроме занимания пространства (хорошо, если не занимает машинные такты). Чисто повторять старую функциональность присвоения значения! 

 

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Новая версия платформы MetaTrader 5 build 5200: расширение OpenBLAS и усиление контроля в MQL5

Ilyas, 2025.08.04 14:08

Из аналогичных измненений в скором будущем - это запрет на вызов оператора = по наследованию, пример:

struct A
  {
   int x;

   int operator=(int y)
     {
      x=y;
      return(x);
     }
  };

struct B : A
  {
  };

void Test()
  {
   B b;
   b = 42;   // БУДЕТ ОШИБКА КОМПИЛЯЦИИ,объект B не имеет оператора 'B::operator=(int)' (хотя он есть у родителя)
  }
Разве операторы не должны вести себя так же, как методы?
 
Ilyas #:

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

Просьба показать пример.

 
Georgiy Merts #:

Ээээ... А как же наследование и перегрузка функций? 

Или это касается только оператора присваивания? 

Иногда очень удобно, когда в объект добавляется новая функциональность - остальные функции продолжают работать, как у старого объекта! 

А тут, получается, в приведённом коде - объект уже нельзя присвоить, надо вписывать новую функцию присвоения, которая, фактически, ничего не будет делать, кроме занимания пространства (хорошо, если не занимает машинные такты). Чисто повторять старую функциональность присвоения значения! 

Касается только оператора присваивания.
Оператор присваивания особенный, т.к. для объекта всегда будет генерироваться неявно оператор копирования [ например, для A будет создан оператор A& A::operator=(const A&) ] , если он явно не задан пользователем, этот неявный оператор копирования будет скрывать наследуемые операторы присваивания.
На самом деле, данный вопрос про запрет пока ещё открыт, но скорее всего будет введён.

Для облегчения жизни писателям, будет добавлено (не сразу) ключевое клово using, которое позволит использовать скрываемые методы (в том числе операторы =) без надобности создавать в протомке функции, которые выполняют лишь "проброс" вызова в базовый класс:

struct B : A
  {
   using A::operator=;
  };

для B будут доступны все операторы= из A
 
Ilyas # :

Касается только оператора присваивания.
Оператор присваивания особенный, т.к. для объекта всегда будет генерироваться неявно оператор копирования [ например, для A будет создан оператор A& A::operator=(const A&) ] , если он явно не задан пользователем, этот неявный оператор копирования будет скрывать наследуемые операторы присваивания.
На самом деле, данный вопрос про запрет пока ещё открыт, но скорее всего будет введён.


В любом случае использование перегрузки оператора ''operator=" в иерархии классов — не опасная идея, если только вы не знаете наверняка, что делаете.

 
anotherfxtrader # :
Спасибо Ренат за ответ . Скажите, не ли планах добавления возможности отключения логов ?
Renat Fatkhullin # :

Зачем?

Для тестера мы в последних бетах сделали агрессивное удаление логов, чтобы больше не было файлов в десятки гигабайт.

Есть ли возможность уменьшить задержку записи журнала в файл журнала? Например, если вы встретите сообщение «Tester job 7534761704468017792 received from Cloud Server», это будет отличным моментом для безусловной записи буфера в файл журнала. А если вы увидите сообщение «Tester optimization pass 1935115 started», это будет отличным моментом для проверки количества секунд с момента последней записи журнала, и для записи в файл, если с момента последней записи прошло, скажем, более 10 секунд. API GetTickCount64 отлично подходит для определения таких интервалов. В настоящее время запись в журнал довольно нестабильна: иногда она задерживается на минуты/часы, а иногда выполняет несколько избыточных записей подряд. Я видел, как агенты работали часами без перерыва, и последней записью в журнале было «Tester shutdown tester machine» — ничего не говорило о получении задания или успешном завершении проходов. Только при ручной остановке агента он сбрасывал свой журнал в файл, показывая, что он либо завершал проходы (или не завершал их) в течение всего этого времени интенсивной обработки. Было бы неплохо периодически записывать в файл журнала какую-либо индикацию хода выполнения в течение таких длительных марафонов, чтобы отражать состояние процесса (и сохранять информацию о задании и его прерывании в случае сбоя), вместо того, чтобы обычно дожидаться завершения задания (или сотен выполненных проходов) перед сбросом чего-либо в файл журнала.


Original English:

Any chance you can improve the latency of flushing of the log entries to the log file?  For example, encountering "Tester job 7534761704468017792 received from Cloud Server" would be a great time to unconditionally flush the buffer to the log file.  And seeing "Tester optimization pass 1935115 started" would be a great time to check how many seconds since the last log flush, and flush to the file if more than, say, 10 seconds has elapsed since the last flush.  The GetTickCount64 API is great for determining intervals like this.  Currently, log writing is quite erratic; at times holding back for minutes/hours, and at times making multiple redundant writes in a row.  I have seen agents working for hours without break, and the last log entry was "Tester shutdown tester machine"—nothing stating it had received a job, or was successfully completing passes.  Only upon manually stopping the agent would it flush its log to the file, revealing that it either was (or was not) completing passes during all that busy processing time.  Some sort of progress indication being written to the log file periodically during such long marathons as an indicator of life (and to store a record of a job and its abortion in the event of a crash) would be a good idea, instead of typically waiting until a job is done (or there have been hundreds of completed passes) before flushing anything to the log file.

 
Ilyas #:

для объекта всегда будет генерироваться неявно оператор копирования [ например, для A будет создан оператор A& A::operator=(const A&) ] , если он явно не задан пользователем, этот неявный оператор копирования будет скрывать наследуемые операторы присваивания.

Самому не получается такое задать.

struct A
{
  int i;
  
  A& operator=( const A& ) { return(this); }
};
 
fxsaber # :

Самому не получается такое задать.

Подождите новый компилятор...

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