Errors, bugs, questions - page 2754
![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
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.
And it will be a solution not for one particularMqlTick structure, but for all occasions
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
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
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 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.
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.
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
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 ))))
not 0 as at present, i.e. effectively REASON_PROGRAM
When restarting the terminal, it writes continuously and non-stop to the record log
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.