|
Hello Bob, Me: >Interesting, I would expect automatic storage to be reinitialised >regardless of activation group persistence. You: >Simon, given all of the great information that you share with the mailing >list, I was surprised by your last statement (above). Perhaps I >misunderstood. Just me not being clear in what I meant -- but that's OK. I'd pick others up on such things so it's only fair to get it in return :) I didn't spend much time thinking about the example code -- which is using static storage anyway. I read the statement "all the storage associated with that program is still allocated and in a 'last-used' state" as meaning ALL storage and not just all static storage and was surprised by the implication that automatic storage would retain state. My use of the word 'reinitialised' was not correct but I tend to think of automatic storage as always being re-initialised due to it being allocated on every call even though I know it's values are undetermined unless explicitly initialised. I should have said "Interesting, I would not expect automatic storage to retain state regardless of activation group persistence". If the declaration of invocation_count in the Apendix H example were moved into main then it would implicitly use automatic storage and would be initialised to 0 on every invocation -- because of the explicit initialiser rather than implicitly regardless of activation group state. >The information cited from the Programmer's Guide applies only to static >data. For C and C++, initialization of automatic storage is not defined by >the language, and, independent of the activation group, automatic storage >is never initialized (by the compiler or machine) for these languages. It >would be very wrong, for example, to assume that automatic variables are >initialized to zero. Not only wrong but dangerous. Hence the convention to initialise variables when declaring them. Automatic variables must either be initialised on declaration, assigned a value before use, or first used to hold a result to ensure valid values -- else they will contain any old value. One thing to note is that this is a language semantics issue and some languages do initialise automatic storage. For Mikes benefit: Variables declared outside a function (by convention, above main but actually anywhere in the source) are implicitly static and generally have global scope. Variables declared inside a function are implicitly automatic and generally have local scope. The static and auto modifiers can be used to override the default behaviour. If I have some function that declares and initialises variables they will always be set to that value because the storage is implicitly declared as automatic and therefore allocated on every call. For example: int someFunction( void ) { int count = 0; count++; return count; } will always return 1. However If I forget to initialise and declare count as int count; then the returned value could be any number at all. If I specify the static modifier and declare static int count = 0; then the count will increment on each invocation unless the activation group containing the storage is destroyed between invocations. If I attempt the same thing in main(), e.g., int main( void ) { static int count = 0; count++; return count; } and expect the count to increment I will be disappointed unless I also use a named activation group. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp spe . «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» +--- | This is the C/400 Mailing List! | To submit a new message, send your mail to C400-L@midrange.com. | To subscribe to this list send email to C400-L-SUB@midrange.com. | To unsubscribe from this list send email to C400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: bob@cstoneindy.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.