Due to text scrolling off screen, your comments text is difficult to follow, especially the example code.
So, I have reformatted your post and copied those comments to regular text
Please edit and correct them if I did not do them proper justice
Due to text scrolling off screen, your comment text are difficult to follow, especially the example code.
So, I have reformatted your post and copied those comments to regular text
Please edit and correct them if I did not do them proper justice
Well, yes, I suppose thats much better. - Thank you for the effort.
I myself edited the preprocessor outputs already, as it was way to much text on one line.
Its difficult to keep track of all the brackets and "capsules" inside that one line of code.
Are your books one column but two feet wide? No because that is unreadable. They are six (6) inches, sometimes two columns, so you can read it easily. So should be your code. I'm not going to go scrolling (or moving my eyes) back and forth trying to read it. Don't copy and paste code, write self documenting code. Please edit your post and you might get additional help.
Hmm,
the possibilities of #define should simplify the code and make it easier to read, you push it so far (too far?) that the opposite happens.
Besides, you could actually find the errors quite easily with search and replace.
You can use the "\" character to break-down your macros into multi-line and make them more readable. Here is an example:
// Define macro for error status #define MReportError( _text ) \ PrintFormat( "%s — Error %d: %s (%s,%d)", \ g_sProgramName, _LastError, _text, \ __FUNCSIG__, __LINE__ )
Hmm,
the possibilities of #define should simplify the code and make it easier to read, you push it so far (too far?) that the opposite happens.
Besides, you could actually find the errors quite easily with search and replace.
Are your books one column but two feet wide? No because that is unreadable. They are six (6) inches, sometimes two columns, so you can read it easily. So should be your code. I'm not going to go scrolling (or moving my eyes) back and forth trying to read it. Don't copy and paste code, write self documenting code. Please edit your post and you might get additional help.
Possible error in the preprocessor stage of the compiler.
For some reason, the preprocessor keeps substituting the same macro over and over again, though, it should stop after first substitution.
To narrow down the issue, all relevant code is provided here.
Concerning the macro ___DBG_MSG_VAR()
Expected behaviour would be, and this was verified with g++ compiler. The parameter passed to the macro ___DBG_MSG_VAR() should only expand once. Even if it is another macro, which it is in this case.
But the result shows multitude of substitutions of the same macro, creating a substitution loop, which is in contrast to g++ compiler for sure not the expected or wanted behaviour.
Here is what actually is produced by the preprosessor stage:
And this is the result from the g++ compiler, using the -E option.
I have aligned the outputs, it is relevant to scroll all the way to the right to see the difference in results.
Anyways, the code produced by the MQL-Preprocessor lets the program crash harshly, resulting in:
Access violation at 0x00000273C7E21008 read to 0xFFFFFFFFFFFFFFFF in 'LibDebug.ex5'
Additionally, I noticed the macro-operator # for stringifying, does not work properly, as it removes all '"' instead of escaping them properly, also whitespaces are being removed, giving false results in the outcome.
As a note:It was quite difficult to track down this issue, as there is very limited way of debugging macros in the first place, and MQL-Compiler not providing output of the produced results of the preprosessor-stage makes things even harder.
I tried best by applying the stringify-macro to the end-results, but this still could influence the interpretation of the results, as to above mentioned issue with the stringify-operator.
This (assumed) bug in the preprocessor stage of the compiler hinders me on finishing the project, which can be found here on code-base:
EDIT:
I have updated the code for better readability... - I hope it is good enough
I would have similar request to what I already asked you in your library topic.
You provided a code with 1500 lines, a lot of them being commented. I opened it, check 2 minutes and I am discouraged, how could I know I will not waste 1 hour of my time reading, trying to understand, etc... to just discover that you made an error and it's actually not a preprocessor bug ? You compared to g++ preprocessor but who said mql5 preprocessor should work the same as g++ one ? This is for sure not the case and that's not bug but MQL limitations.
If you want MetaQuotes to consider it you would need to narrow down that more. As least it's my opinion, I can't help like it is currently, sorry.
I would have similar request to what I already asked you in your library topic.
You provided a code with 1500 lines, a lot of them being commented. I opened it, check 2 minutes and I am discouraged, how could I know I will not waste 1 hour of my time reading, trying to understand, etc... to just discover that you made an error and it's actually not a preprocessor bug ? You compared to g++ preprocessor but who said mql5 preprocessor should work the same as g++ one ? This is for sure not the case and that's not bug but MQL limitations.
If you want MetaQuotes to consider it you would need to narrow down that more. As least it's my opinion, I can't help like it is currently, sorry.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Possible error in the preprocessor stage of the compiler.
EDIT:
I have updated the code for better readability... - I hope it is good enough
And here is a stripped version of the embedded issue at hand: