Errors, bugs, questions - page 2754

[A100]

fxsaber:

The point is to be able to pass by reference.

As well as with strings, the Developers have an opportunity (if not already done) to pass everything by reference without actually copying the variable.

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

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

And it will be a solution not for one particularMqlTick structure, but for all occasions

[Ilyas]

A100:

Which once again confirms that there is no sense inusing _Digits,_Point , _Period, _LastError, etc.directly(and even _Symbol can be replaced by NULL). In fact, they must be declared as const volatile

And you, on the contrary, are proposing to enlarge this range

You're right, but they arealmost volatile, except for the flag IsStopped - it is 100% volatile, i.e. any reading of IsStopped is 100% memory reading.
For others,almostvollatylе means the compiler MAY cache the value of a variable in a register at first call and use cached value at next call to such variable, but only within one function or branch of calls, if they are inlined in one function.
This is possible (and necessary) because changing predefined variables (except IsStopped) cannot happen inside an MQL entry point (OnXXX function)

Regarding theVARIABLE VARIABLE MODIFICATOR, let's say it's used by const programmers for programmers.
As we know, you can change the constant of a variable through conversion, so the compiler cannot be trusted with the const modifier.
If the compiler sees that the variable hasn't changed its value and is initialized as a constant, it will turn such a variable into an immediate value (ImmediateValue) even without the const modifier

. Concerning _LastTick, we are discussing but...
This is a structure, not a simple atomic type and it can be changed all of a sudden, at any point of the MQL program, including the time of getting the value.
It turns out that in order to address this structure you need to introduce a synchronizer.

We are constantly working on performance, in particular, because of this high release rate of builds.
We plan to do a lot of work to speed up the MQL code

[Igor Makanu]

Ilyas:

Regarding _LastTick, we are discussing, but...

This is a structure, not a simple-atomic type and it can be changed suddenly, at any point of MQL program, including the time of getting the value.
It turns out that in order to address this structure we need to introduce a synchronizer.

but in tester _LastTick cannot change at any point of MQL program ?

if yes, then give such solution only for tester, where speed of calculations is most important

[Alexey Navoykov]

Igor Makanu:

but in tester _LastTick cannot change at any point of MQL program ?

if yes, then give such a solution only for the tester where speed of calculation is most important

So, what prevents you from requesting this tick once in the OnTick handler, and then from working with the obtained data? It practically costs nothing. Why should I request it 100 times (as in the above tests), artificially creating brakes on an even place? So, the problem of a crooked EA code is suggested to solve by complicating the internal work of MT. Or do you have some normal measurements?

[fxsaber]

Alexey Navoykov:
So, what prevents you from requesting this tick in the OnTick handler once and then working with the received data?

The low qualifications of the EA creators with which Market and Cloud are loaded are a hindrance.

[Maxim Kuznetsov]

Alexey Navoykov:
So, what prevents to request the tick once in the OnTick handler, and from further work with received data? It practically costs nothing. Why re-request it 100 times (as in the above tests), artificially creating brakes in place? So, the problem of a crooked EA code is proposed to solve by complicating the internal work of MT. Or do you have some normal measurements?

The events to be handled by "OnTick" are received externally in some queue with priorities. In other handlers, it is useful to make sure that no such new events have occurred, otherwise the data of the previous tick is invalid/outdated.

[Igor Makanu]

Alexey Navoykov:
So what prevents you from requesting this tick once in the OnTick handler and then working with the resulting data? It's practically worthless. Why bother requesting it 100 times (as in the above tests), artificially creating a brake on the spot.

This is exactly what I do in the tester

Alexey Navoykov:
I.e. the problem of a crooked EA code is supposed to be solved by complicating the inner workings of MT. Or do you have some normal measurements?

Well, the code is determined by common coding practices, look at QB and use of safelines in these examples

I don't use SB, I've been measuring with a profiler and looking for solutions for months, there was a thread about speed tests, partly throwing in alternative solutions

the normality of the metering? it's a slippery slope that will have to be dealt with seriously, i am happy with my EA for optimisation, there was a pass at 18 months 6 sec, now 2.5 sec , imho i have done a good job on myself ))))

[A100]

According to the materials of .... the following considerations have arisen:

Given that UninitializeReason() can be called in any part of a program, particularly in OnInit() (and if such a call was not intended, the scope could be extended)

It is suggested:

If the value of the _UninitReason variable is generated before OnDeinit() is called,

and if the reason for previous deinitialisation of the EA cannot be defined (REASON_PROGRAM, REASON_REMOVE, etc.)

it should be undefined (-1) before this call. This is now 0, i.e., effectively REASON_PROGRAM

If the EA is completely restarted(REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, etc.), then

it seems possible to set the _UninitReason variable to an appropriate value (REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, etc.) when starting a new instance of a program,

not 0 as at present, i.e. effectively REASON_PROGRAM

If an Expert Advisor is partially restarted (REASON_CHARTCHANGE, etc.), the _UninitReason variable in OnInit() is still equal to the corresponding value (REASON_CHARTCHANGE, etc.),

and no change is needed

[Sergey Dzyublik]

MT5 bug (build 2450) compilation error for forward declaration of template class method.

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]

When restarting the terminal, it writes continuously and non-stop to the record log

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

History bar time in the log is constantly increasing. GBPUSD Daily chart is open and fidgeting - zero, first and second bars are deleted/created. And so it goes round and round.

Here I am waiting. Will it fill all SSD with these logs or will it stop at last...

Yesterday's log is in the trailer.