How do I go through an enumeration consistently? - page 3
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 examples shown here (case 1: return value1; case 2: return value2; case 3: return value3... An adequate person would put all values into an array and just get the required value by its index. And for the reverse task he/she would use binary search.
I'm two hands in favour of nice code with arrays. But when writing a faster NormalizeDouble than the regular one, I have encountered an optimizer effect - a nice solution via const-array was much slower than a cumbersome one via switch-case. I have left the second variant because NormalizeDouble is used a lot in the tester. I put it into the indicator and don't look at this monster. But the backtests run faster.
I remember once there was a thread discussing switch, where developers were only talking about implementation as a binary search, which of course is much slower than simple access by calculated index.But now they seem to have made it more wisely: if a step is constant, the index is calculated, otherwise binary search is performed. Of course, native implementation is always faster than wrapper one.
Of course, this depends on your priorities. But imho, if speed is so crucial that you're ready to invent crutches, then you should give up OOP and MQL as well ;) Although I'm sure with proper coding this difference in speed won't be that significant. In testing measurements you are just bouncing a function around in a loop millions of times. And you use it more rationally in real code, don't you?
I remember once there was a thread discussing switch, where developers were only talking about implementation as a binary search, which of course is much slower than simple access by calculated index.But now they seem to have made it more wisely: if the step is constant, then the index is calculated, otherwise binary search. Of course, native implementation is always faster than wrapper one.
The compiler, if it is not dumb, would have to turn the const-array and the only type reference to it by the index into switch code.
Of course, you may have to depending on your priorities. But imho, if speed is so crucial that you're ready to invent crutches, then you should give up OOP and MQL in general ;) Although I'm sure with correct coding the difference in speed will not be so substantial. In testing measurements you are simply racing a function through a loop millions of times. And in real code you use it more rationally, don't you?
The compiler, if it is not dumb, would have been obliged to turn the const-array and the only type reference to it by index into switch code.
So the array is just a const? What about static? And why "switch code"? It's a simple operation: compare index value with array/enum size, and if it's less, get the address of the required element as array address + index, and then read the value from there. I thought such nonsense must compile equally.
So the array is just a const? What about static? And why "switch code"? It's a simple operation: compare index value with array/enum size, and if it's less, get the address of the required element as array address + index, and then read the value from there. I thought such nonsense must compile in the same way.
I don't remember for sure whether you may create static arrays using const methods - you certainly may not. As a matter of principle I was making consts and not statics. Counting on the compiler's intelligence. After the compilation, there should have been no hint of an array in the guts at all. A statik is a much more complicated structure than const. That's why I was sure the compiler would fail to cope with the statik. But I would have to give it a try.
I don't remember exactly whether static arrays can be made const. methods - definitely not. As a matter of principle, I was making consts, not statics. Counting on the compiler's intelligence. After the compilation, there should have been no hint of an array in the guts at all. A statik is a much more complicated structure than const. That's why I was sure the compiler would fail to cope with the statik. But I would have to give it a try.
Oh, well, that explains it. You should not rely on excessive intelligence of the compiler, that it further optimizes a poorly-designed solution for you. If you yourself are too lazy to do it properly, saying that "statics is much more complicated" (although what is complicated there, I do not understand), then why accuse the compiler?
Oh, well, that explains it. You should not rely on excessive intelligence of the compiler, as it will optimize a poorly-designed solution for you. If you yourself are too lazy to do it properly, saying "static is much more complicated" (although what is complicated there, I do not understand), then why accuse the compiler?
You're welcome. It will be a lesson for the future, that one should think 7 times, before running to invent crutches.)
It turns out now, that I praised the switch, or rather its developers too early. So everything is implemented there through binary search only, even when enumeration goes with multiples. Not good.
You're welcome. It'll be a lesson for the future, to think 7 times before running around inventing crutches )