|
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-2025 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.