Features of the mql5 language, subtleties and tricks - page 51

[Stanislav Korotky]

fxsaber:

That's a good trick. The trick is to apply the pattern to TParent. I haven't seen anything like that before.

Well, it's not multiple inheritance. It's actually a chain Base -> A -> B -> C -> X. Who prevents you from using it directly, if that's enough?

[fxsaber]

Stanislav Korotky:

Well, it's not multiple inheritance. It's actually a chain Base -> A -> B -> C -> X. Who prevents you from using it directly, if that is enough?

Brevity.

[Stanislav Korotky]

fxsaber:

Brevity.

I couldn't agree more. IMHO, it would be shorter and clearer to directly spell out the four successor classes.

[fxsaber]

Stanislav Korotky:

I can't agree with you there. IMHO, it would be shorter and clearer to spell out the four inheritance classes directly.

If, suddenly, multiple inheritance will be introduced, you just need to make a small change in just one line

class X : public INHERIT3(A, B, C)  {  };   // Объявляем класс, наследуемый от A, B, C

[Stanislav Korotky]

fxsaber:

If, suddenly, they introduce multiple inheritance, all you need to do is make a small substitution in just one line

Too bad the forum doesn't have a betting form in addition to polls - like a poll with options, but blocking a few "pennies" in the account for the answer. Those who choose the right option, after the event would get the bets of the losers ;-). I don't think they would introduce it.

[Alexey Navoykov]

Stanislav Korotky:

Well, it's not multiple inheritance. It's actually a chain Base -> A -> B -> C -> X. Who prevents you from using it directly if it's enough?

Yes, but the whole peculiarity here is that all the source classes are defined and used as templates. Therefore this chain can be set in any order. And in essence there is no fundamental difference with multiple inheritance. As I've already written, there can be pitfalls with classes. As for interfaces, everything is identical. The only thing that it will look a little crusty, but here everyone will decide for himself, check or go)

[Alexey Navoykov]

One more thing I'd like to add. A complete alternative to multiple inheritance (and with more flexible options) could be implemented via overloading the ghost operator. But MQ for some reason will not add this overloading feature, although I've been asking them to do so for a long time. And I haven't even heard a concrete answer from them, they just ignore it.

[fxsaber]

There are such situations

Forum on trading, automated trading systems and trading strategies testing

Bugs, bugs, questions

fxsaber, 2017.07.24 09:27

EA is compiled under 1641, where fast trading history is implemented.

Is it possible during optimization to get to Agent build 1596, where the history works VERY slowly, and, accordingly, get a slowdown in optimization by times?

As a more general case, optimization on the Cloud sometimes gives different results not only in terms of time, but also in terms of calculations. Sometimes you may hear that the optimization result does not coincide with a single run.

It can be explained by the fact that Agents participating in optimization and a local Agent participating in a single run can have a different build number.

And each build contains different bugs. For example, here is a bug that is relevant now but was not present in several previous builds

Forum on trading, automated trading systems and trading strategies testing

Bugs, bugs, questions

fxsaber, 2017.07.17 23:08

Once again the HistorySelect bug in the tester. In 1626, it didn't seem to be. In 1629 - there is.

#include <Trade\Trade.mqh>

void OnTick()
{
  static CTrade Trade;

  const datetime NowTime = TimeCurrent();
  
  if (Trade.Buy(1) && Trade.PositionClose(_Symbol) && HistorySelect(NowTime, NowTime))
  {
    Print(HistoryDealsTotal()); // 0 - это при том, что мы открыли и закрыли позицию в NowTime-время
      
    ExpertRemove();
  }
}

Accordingly, if your EA gets on Agent b1626 during optimization, it may show one result, and when running on the local Agent b1641 single run - quite different.

This leads us to the conclusion that you should know before the optimization what builds you want to optimize your EA for and what builds you don't.

The developers have provided a cutter for the unsuitable Agents - INIT_AGENT_NOT_SUITABLE.

Therefore, I would recommend writing a check for matchingTerminalInfoInteger(TERMINAL_BUILD) to your desired values in OnInit for Cloud based optimizations.

But it is almost impossible to know the list of checks that match your needs, so you must most likely write this

int OnInit( void )
{
  // Если Агент не совпадает с билдом компиляции, отказываемся от его услуг
  if (TerminalInfoInteger(TERMINAL_BUILD) != __MQLBUILD__)
    return(INIT_AGENT_NOT_SUITABLE);
//....

But this is also a bad solution. A more flexible solution is to pass your build number to Agents during optimization.

In general, be vigilant.

SZY. It is possible to generate a trade report for each Agent's run and get it right away during optimization. This can help you understand later why the Cloud Agent's result is different from the local one during a single run. Automatic generation of such reports during Optimization and Single Run is possible with the help of this library.

Forum on trading, automated trading systems and trading strategies testing

Bugs, bugs, questions

Renat Fatkhullin, 2017.07.25 08:26

We periodically cut off old builds in the cloud, waiting for them to be updated, which goes very quickly and unnoticed.

This is not done every version, but depending on the importance of the changes made.

[fxsaber]

When debugging (not necessarily debugging), when you need to quickly reduce the test interval in the tester, I use the following functions

// Выгружает эксперт, если количество сделок в истории больше DealsNum.
void ConditionStopExpert( const int DealsNum = INT_MAX )
{
  if ((DealsNum != INT_MAX) && ::HistorySelect(0, ::TimeCurrent()) && ::HistoryDealsTotal() > DealsNum)
    ::ExpertRemove();

  return;  
}

// Выгружает эксперт, если с момента запуска прошло AmountHours-часов.
void ConditionStopExpert( const double AmountHours )
{
  static datetime FirstTime = ::TimeCurrent();
  
  if (::TimeCurrent() > FirstTime + (datetime)(AmountHours * 3600))
    ::ExpertRemove();

  return;  
}

[Alexey Navoykov]

fxsaber:

When debugging (not necessarily debugging), when you need to quickly reduce the test interval in the tester, I use the following functions

Correct the code, you have a number 5 there in the first function instead of DealsNum.