Errors, bugs, questions - page 707
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
A replacement could be a native index table - but then I can't make a class encapsulating work with an array of structures with possibility of its inheritance together with once specified services (sorting and binary search).
I see - it was not about a specific solution, but about abstract possibilities.
If you want to work effectively at the edge of external systems, write site-specific code, rather than trying to make a universal solution that contradicts security issues.
No, we will not do such handels. This is outright evil, for which we will be held accountable to the end.
There's not much to answer for. You can't see the dangers.
I pointed out the inevitability of a huge handlap table. It's a huge evil.
You yourself don't even want to work with indexes, telling how inconvenient it is for you, and then suddenly a huge and slow table of handles inside MQL5 "does not represent any danger".
Renat:
..........., rather than trying to make a one-size-fits-all solution that contradicts security issues.
Renat, give me at least one example of a dangerous use of a handle on a structure. I stubbornly don't see it. I'm trying to think of one and can't find it. Maybe I missed something?
--
What about parametrized structures? Are there any in the long term? Everything is solved there at the preprocessor level, so security issues are generally out of the question. And a lot of problems related to handy data containers would be solved very nicely and compactly.
1. I pointed out the inevitability of a huge handle-matching table. This is a huge evil.
You yourself don't even want to work with indexes, you are telling me how inconvenient it is and all of a sudden a huge and slow table of handles in MQL5 "does not represent any danger".
1. The table isn't huge, it's what the user "handled" - dynamically expandable. Strings are evil then, too. Then let's make 128 symbols limit per line. Then there will be less evil in the world, right? :)
2. I even really want to work with indexes. I just don't want to work over and over again - I want to inherit my work and reproduce it when needed, not rewrite it (with new errors with sloppy copy-paste corrections).
But I'm not even talking about it anymore, maybe I should?
1. the table is not huge, but as the user "nahndled" - dynamically expandable. strings are then evil too. Then let's make 128 symbols limit per line. Then there will be less evil in the world, right? :)
Strings are internally bound and no one requires it externally. That is, we don't need to maintain publicly-operated handles displayed through tables. Everything is quick and hidden there.
"User nahndled" - that is a huge and braking table.
We're not going to create a problem for ourselves out of the blue. So let's not overstress the subject - this issue is closed and no arguments can change it.
What about parametrized structures? Are there any in the long term plans? Everything is solved at the preprocessor level there, so security issues are generally out of the way. And many problems related to usable data containers would be solved very nicely and compactly.
Templates are not yet in the plans.
Right now we're releasing static class memes and operator overloading.
We are now releasing static class memes and operator overloading.
1. templates are not yet in the plans.
2. we are now releasing static class memes and operator overloading.
1. Too bad, maybe you should plan it.
2. thank you very much humanly for this, I'm looking forward to the build.