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 Compile button is lost forever (you have to reload the editor to get it back)
Well, not exactly... :) I managed to get it back :)
You have to comment out the recursive piece and press the debug compile button to do it.
1. it is not safe to "expose" internal non-base class elements to the outside (and in this example, not the attribute itself, but only an array element!) Moreover, it is not possible to change its value.
Besides, it contradicts the "spirit" of object-oriented programming: all the work with the object's data should be performed inside the object, by its own methods...
3. How about just using Setter for data attribute?
4. The code would benefit from readability.
5. eventually this "simplicity" with l-value indexer will make nobody including you understand how this code works...
6. you will spend more time searching for errors than writing Setter.
What is that, black humor?
1. Sorry, - nonsense. I understand paranoia is in vogue here, and is a scrap argument for "why you shouldn't do that". I don't see any danger in it. Looked at it carefully, if anything. Any name, after all, is a reference. Indexing is just an extension of the name concept. Nothing more. Let's ban naming altogether. For safety's sake. Links are extremely dangerous, aren't they?
2. That logic violently contradicts the spirit of object-oriented programming with C++, C#, Delphi and a couple dozen less popular languages where indexers work quite well both on the right and on the left. Moreover, it does not contradict common sense and my spirit for some reason.
Indexers are made to communicate with the external environment. Their function is exactly that of an interface. I can encapsulate and hide anything, but I need indexes to operate with objects as arrays. In fact, all arrays are arranged somehow. For example, regular dynamic mql arrays. May we prohibit to put them on the left side of the assignment operator? Let's replace them with a function like SetArrayValue(array, i, j, value); this will simultaneously improve readability. And debugging will also become much easier. Ugh...
3. What about making a normal indexer? The maid is cool, of course, but the queen is still better.
4. This is where I'm really starting to lose my mind. Is that unreadable?
That's more readable, isn't it?
t.setDataElement(i, i*i);
Cool. I think I'm gonna go get treatment.
5. Cool.
6. I cried.
The indicator stopped compiling on build 630:
c i error can be eliminated by putting an ad in front of for
And what to do with'rates_total' - undeclared identifier ?
Same on Win7 x64 and XP x32.
Can you tell me please. Are MathMin() and MathMax() implemented as functions (withparameters passed through stack) or macro substitution(inline)? According to the handbook, these are functions.
The indicator stopped compiling on build 630:
c i error can be eliminated by putting an ad in front of for
And what to do with'rates_total' - undeclared identifier ?
Same on Win7 x64 and XP x32.
You clearly have an error somewhere in your code. The submitted block compiles without errors if you declare variables limit, RT and set condition if()
Naturally, I didn't give the code, but an approximate structure.
On the 619 build the indicator compiled and worked fine.
On 630 it generates the above errors.
The code is 100% unchanged. The way the compiler works has obviously changed.
Bug?
The code below generates a sort of perpetual loop in the compiler. Clicking Cancel
doesn't work right away, but when it does, it regains control of the editor.
The Cancel button itself does not disappear, but it is not accessible either.
The Compile button is lost forever (you have to reload the editor to get it back)
Please advise. Are MathMin() and MathMax() realized as functions (withparameters passed through stack) or as macrosubstitutions(inline)? According to the reference book, they are functions.
Of course functions, because at the time of compilation the values of the arguments are unknown. IMHO inline and macros are different.
P.S: inline or not inline I can't say.
Of course functions, because at the time of compilation the values of the arguments are unknown. IMHO inline and macros are different.
P.S: whether they are inline or not I cannot say.
A macro and inline function are indeed different things. But that's not what I mean. Here is an example when at the moment of compilation the arguments' values are unknown
In the first case, the code must be pasted into the current function (I guess) and in the second case, the function is called with parameters passed through the stack (I guess). But for the purpose of optimization, the compiler may actually implement the second variant through substitution as well. Is it so? I do not know. That's why I asked.