Errors, bugs, questions - page 1016
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
Yes, thanks, I made a mistake in simplifying the source code - now I've rewritten the error differently
I deleted the previous one to avoid confusion.It's terrible. It really is. What a terrible thing to live...
--
Listen, what's in it for you? If it's no secret.
You write your advisor in Lisp? My hat's off to you, but I suggest you switch to Haskell.
;-)
Listen, what do you need it for? If it's no secret.
MQL5 has no inline functions (in form) and I use parametric macros instead.
Yes, I use them too, just not so creepy nesting. ))))
For your reference, mql5 translates all small functions to inline substitution. In other words, we can assume that the keyword "inline" is in every user-defined function by default.
The decision to substitute a macro or compile into a function is ultimately made by the compiler (just like C++, by the way). So there is no point in trying to speed things up that way, all simple functions are inlined anyway.
// And by the way - with type control! :)
For reference, mql5 translates all small functions into inline substitutions. In other words - you can assume that the keyword "inline" is in every user function by default.
https://www.mql5.com/ru/forum/1111/page1013#comment_520221
There B() in 1.mqh is supposed to be inline - but all together - does not compile normally - only separately. ServiceDesk referring to the ambiguity of the call did not go deep into the essence of the problem and recommended to organize the project in a different way. How could it be done differently? Everything works only when I remove the B() implementation from .mqh to .ex5. And what is the inline form then?
By the way, in MQL4, that example works - without errors, although B() is not inline in fact, but in form - inline.
And I didn't do it for speed, I did it for convenience. In essence they may be inline, but not in form(!).
And what about the form.
" Who is a Studebaker? Is that your Studebaker relative? Your daddy's a Studebaker?"
Difficulties arise if you define inline in .mqh and then use it in several .ex5.
There are no difficulties. If you do not make logical mistakes and properly understand how a compiler works.
I'll try to find the link now
https://www.mql5.com/ru/forum/1111/page1013#comment_520221
The B() function here is essentially inline
I haven't managed to get rid of errors like "ambiguous call to overloaded function with the same parameters" - they didn't occur unless you put it into a separate .ex5
You have essentially unrecognizable recursion at the source code level there. The compiler frowned upon you mercifully, right on the merits. You're trying to connect to the inluder a libu, which defines the same inluder you're compiling into. So what do you want? If you were a compiler, what would you do?
This may be news to you, but an inline function written in a DLL can in no way be used as a macro outside of this DLL. // In runtime the source code no longer exists
I guess the second news for you: all the libs in mql(4, 5) are dynamically linked. That is DLL's essentially.
Bottom line: you were actually trying to refer from a lib to itself, referring to itself, referring to itself...... etc.
Agree, it would be much worse if it all compiled without objection, and then at runtime the lib tried to load itself recursively until it ran out of memory.... :))
?
That's why there is the inline keyword in C/C++
That's not the reason at all. I'm sure the example at the link won't compile in C++.
// I'm too lazy to check. It just doesn't make sense. If I don't understand how to build recursively organized source code, the compiler won't understand it either.
By the way, that example works in MQL4 - without errors, although B() is not inline, but in form - inline
I don't. Although... since there's no function overloading there, maybe the compiler doesn't try to hint at a wrong overloading there - it just stupidly ignores repeated definitions.
It compiles in MQL4 (!) and in C/C++ if you write inline before B()
There is no recursion there at all, in fact there is
int A( int ) and #define B() A( 0 )
It's very simple there - if you're not too lazy - have a look on your fresh head - just separate declaration and implementation of functions :)
There B() in 1.mqh is supposed to be inline - but all together is not compiling normally - only separately. ServiceDesk referring to the ambiguity of the call has not gone deep into the heart of the problem and recommended to organize the project in another way. And how else?
It only works if you remove the B() implementation from .mqh in .ex5. What is the inline form then?
You just answered your own question:
The inline is normal there. The problem there is not inineity of B() at all, but in its redefinition.
It's just that C/C++ understands (using inline keyword) that this is not a redefinition, and MQL5 does not, although it can distinguish by the name of compiled module and one specified in #import. I don't know how MQL4 understands it.
In short, you can't define an implementation of a function in .mqh and use it without any problems in any .ex5.
Exactly right - it's just that C/C++ understands that this is not a re-definition, and MQL5 does not.
C/C++ are able to understand this ONLY when compiling a static lib, because the source name information is stored in the object file (just to recognise recompilation).
With dynamically linked libraries this will not work and if it does it is not because of reimplementation detection but because of "priority rules" for the naming congruence of current source and DLL. Some languages have such rules (Delphi in particular, probably some C/C++ compilers have them too).