June 24th, 2008, 11:46 AM
Is func() local array declaration stack based? As MQL4 thinks is static...
I seem to only work in MQL4 for last 8/9yrs. Prior to that for 30+yrs was assemblers and many block structured HLL's with C being 'first love' :)
My question is [to me] obvious and I would say yes, of course... all local function decs are transient, have no persistentcy and basically, not have static attribute etc.
But today I am told and some docs bear witness to the 'telling' that arrays declared inside functions are considered static in as much as the values written to the array - so that next function entry, these values are still there. (the docs states this applies only for 's).
Now, for me this is worrying - from my brief bio above, I have always without exception seen local decs as stack based and when function exits, SP is reset via BP....
What am I missing here if anything?
Are C local function decs transient for an array and any values put into the array will only be there until function returns and not there on next entry?
Really would appreciate some feedback.
I reckon that is MetaQuotes method... but hey, I wanna learn more so hit me with it... :eek:
June 24th, 2008, 01:51 PM
What documents? (Link?)
Either they are wrong, or you have misinterpreted them, or they are referring to some non-standard compiler specific feature. In older versions of Rabbit Semi's Dynamic C language for example the default storage class for local variables was static (Dynamic C is however not C, and they have since modified it to behave by default as a C programmer might expect.)
Last edited by clifford; June 24th, 2008 at 02:19 PM.
June 24th, 2008, 03:27 PM
Are you saying that stack is used normally for local C function storage of array? ie, this is the defacto compSci/usual way of allocating temp [for lifetime of function] storage decs.
Originally Posted by clifford
links and "search string to section":
book.mql4.com/variables/arrays "All arrays are static"
book.mql4.com/variables/types#static "All arrays are initially static"
excuse crummy urls but not allowed to post full syntax yet.
It is all about me thinking that stack based stuff is normal... and then all of a sudden I get thrown this curve ball in relationship to MQL4 and how it allocates storage for function() local arrays
Thanking you greatly.
June 24th, 2008, 03:44 PM
Well, all arrays being static may be the norm MQL4 (which I had never even heard of before), but MQL4 is not C.
Every language is free to handle its internals in its own way, hopefully in a reasonable manner.
June 24th, 2008, 05:36 PM
Although auto (local) variables are generally implemented with a stack, there is no requirement in the standard for that particular mechanism. Some early processors (Fairchild F8, for one) had no stack.
Just a point that's not entirely germane to the the topic.
June 24th, 2008, 05:39 PM
No... for sure is not C My knowledgebase was turned upside down regards this 'feature' of MQL4. They bringing out MQL5 which is going to be compiled down to machine code and also more fully comply with C/C++ syntax [with C++ features throttled down] but will be massive improvement. Still, I suspect that they will keep their own brand of doing things - is crazy in my eyes, but then I'm half blind with age anyway ;)
You have been a star Clifford - appreciate your time spent in investigations!
June 25th, 2008, 03:05 AM
sizablegrin,dwise and clifford: all give consensus (as expected really- truth be told). What you have all demonstrated is in many aspects more important to me and that is to look in the mirror and see that although been around for a bit, have also become blinkered. You guys have in your kind answers been valuable - seriously!
Looking back, I now see that used to embrace it all - suck it in and use the environment to fullest and that means warts and all. Not want to be moaner just because something impinges on my corralled mindset... computing was for me at the start in late 60's pure unadulterated magic - no tech background let alone education skills but was pure magic for sure.
Ok... the re-education starts now ;)
btw, have been on numerous forums - here, I feel like have met good people... is rare
June 25th, 2008, 03:26 PM
But auto != local. One refers to storage class, the other refers to scope. Local variables may have either static or auto storage class. But indeed whether or not auto variables are implemented on the stack or otherwise is implementation dependent. On processors with large orthogonal register sets, they are often stored in registers before resorting to the stack.
Originally Posted by sizablegrin
June 25th, 2008, 03:59 PM
It was not at all clear in your original post that you were talking about MQL4 and not C or C++. I assumed that all that preamble was just irrelevant background that many people seem to start there posts with.
This is after all a C / C++ / C# / ObjC related forum; why would we think you were talking about anything else!?
Moreover, why would you expect one language to behave like another - wouldn't that make it rather pointless?
I'd never heard of MQL4 until you had mentioned it, and I never looked at it until it became apparent that was what you were referring to. It is not general purpose programming language - being essentially an embedded macro language in a proprietary application, and you should not let its superficial resemblance to C mislead you.
The links you posted do not reveal the reasoning for this behaviour - proprietary application specific language implementations seldom do, since no one else is expected to implement the language as is the case with an open standard.
The consequence of this restriction is that any array exists for the lifetime of the execution, so it is not memory efficient, and that re-entrant code (either multi-threaded or recursive) would need special attention where arrays are used.
If large arrays are needed, as may often be the case I suppose in MQL4's application domain (who knows, not my domain!), then you would typically create them dynamically or statically in any case, since the stack is a limited resource. For example, an array int would exceed the stack typically allocated to a single thread in Win32 by nearly 100%.
June 25th, 2008, 05:49 PM
Thank you for further inputs.
Please do not trouble self further in this exercise.
Of course, my error for not considering the forum's delimiters.
As I already said, you have reminded me of how easily it is to become blinkered, yes?
Further reminders are not required.
Again, thank you for your time.