Bad compiler optimization?
In code I have the following lines
<CODE REMOVED>
The g_stopBuffer is not drawn on screen i this case. I spent lots of time guessing why, but if I add another couple of lines and get:
<CODE REMOVED>
I got my indicator working! And g_stopBuffer shows up on screen. I got no warning messages about any unused values in the first case. So the only idea I have is that this behavior is due to bad compiler optimization.
Does anyone have other ideas? I think this behavior is horrible, because I spent my time on investigating a bug in my code that doesn't seem to exist!
P.S. I couldn't find how to indent lines here after if and else.
Please read some other posts before posting . . .
Please edit your post . . . please use the SRC button to post code: How to use the SRC button.
Please read some other posts before posting . . .
Please edit your post . . . please use the SRC button to post code: How to use the SRC button.
1) I did. Please be more specific what to read if you consider this answer is so simple and is met all over the forum so many times that anyone can easily find it.
2) Done. Thank you for help
- I don't beleive you. If you had you would have seen numerous requests for using SRC.
if (g_stopBuffer[bar] == EMPTY_VALUE) g_stopBuffer[bar] = g_stopBuffer[bar+1]; //Leave stop like it was else Print("!EMPTY VALUE!!!! : old data, new data", g_stopBuffer[bar], currentStop);
If adding an "else print" changed anything then your problem is likely another if (above) without brackets. Post all the code.
In code I have the following lines
The g_stopBuffer is not drawn on screen i this case. I spent lots of time guessing why, but if I add another couple of lines and get:
I got my indicator working! And g_stopBuffer shows up on screen. I got no warning messages about any unused values in the first case. So the only idea I have is that this behavior is due to bad compiler optimization.
Does anyone have other ideas? I think this behavior is horrible, because I spent my time on investigating a bug in my code that doesn't seem to exist!
In code I have the following lines
The g_stopBuffer is not drawn on screen i this case. I spent lots of time guessing why, but if I add another couple of lines and get:
I got my indicator working! And g_stopBuffer shows up on screen. I got no warning messages about any unused values in the first case. So the only idea I have is that this behavior is due to bad compiler optimization.
Does anyone have other ideas? I think this behavior is horrible, because I spent my time on investigating a bug in my code that doesn't seem to exist!
Change g_stopBuffer[bar]-> gxyzstopBuffer[bar]
- I don't beleive you. If you had you would have seen numerous requests for using SRC.
-
If adding an "else print" changed anything then your problem is likely another if (above) without brackets. Post all the code.
1. Maybe I misunderstood the point of RaptorUK, but I did look for an answer to my question in this forum. I didn't look for SRC, before posting my question, that's true, but I don't think that was the question. I used "code" formatting so I thought that's ok.
2. Thank you for your answer. Here is the code, which may be relevant
if (lastTrendBulls) { double currentStop = Low[bar] - coeffPenetration * averagePenetration; if (currentStop < g_stopBuffer[bar+1] && !shiftStop) //current stop is lower than previous and we shouldn't move it if (g_stopBuffer[bar] == EMPTY_VALUE) // we don't want to overwrite things g_stopBuffer[bar] = g_stopBuffer[bar+1]; //Leave stop like it was else Print("!EMPTY VALUE!!!! : old data, new data", g_stopBuffer[bar], currentStop); else { if (g_stopBuffer[bar] == EMPTY_VALUE) g_stopBuffer[bar] = currentStop; /*else*/ /* Print("!EMPTY VALUE!!!! : old data, new data",*/ /* g_stopBuffer[bar], currentStop);*/ } }
The first "else Print" matters. If comment it, then g_stopBuffer is not shown. BTW, even "else Print("");" helps to show g_stopBuffer
Change g_stopBuffer[bar]-> gxyzstopBuffer[bar]
If you mean replacing in if statement g_stopBuffer with some other stuff, it didn't work. Compile error, so evidently it's used. Though good try
Wow, it seems I missed the braces. My bad! What a stupid mistake really
Thank you WHRoeder for help.
If only I could close the topic which was useful only for me...
| This is your post | double currentStop = Low[bar] - coeffPenetration * averagePenetration; if (currentStop < g_stopBuffer[bar+1] && !shiftStop) //current stop is ... if (g_stopBuffer[bar] == EMPTY_VALUE) // we don't want to overwrite things g_stopBuffer[bar] = g_stopBuffer[bar+1]; //Leave stop like it was else Print("!EMPTY VALUE!!!! : old data, new data", g_stopBuffer[bar], currentStop); else { if (g_stopBuffer[bar] == EMPTY_VALUE) g_stopBuffer[bar] = currentStop; } |
| Removing the else Print and reformatting shows completely different code | double currentStop = Low[bar] - coeffPenetration * averagePenetration; if (currentStop < g_stopBuffer[bar+1] && !shiftStop) //current stop is ... { if (g_stopBuffer[bar] == EMPTY_VALUE) // we don't want to overwrite things g_stopBuffer[bar] = g_stopBuffer[bar+1]; //Leave stop like it was else { if (g_stopBuffer[bar] == EMPTY_VALUE) g_stopBuffer[bar] = currentStop; } } |
| Which is not the same as | double currentStop = Low[bar] - coeffPenetration * averagePenetration; if (currentStop < g_stopBuffer[bar+1] && !shiftStop) //current stop is lower ... { if (g_stopBuffer[bar] == EMPTY_VALUE) // we don't want to overwrite things g_stopBuffer[bar] = g_stopBuffer[bar+1]; //Leave stop like it was } else { if (g_stopBuffer[bar] == EMPTY_VALUE) g_stopBuffer[bar] = currentStop; } |
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
In code I have the following lines
The g_stopBuffer is not drawn on screen i this case. I spent lots of time guessing why, but if I add another couple of lines and get:
I got my indicator working! And g_stopBuffer shows up on screen. I got no warning messages about any unused values in the first case. So the only idea I have is that this behavior is due to bad compiler optimization.
Does anyone have other ideas? I think this behavior is horrible, because I spent my time on investigating a bug in my code that doesn't seem to exist!