may seem funny but i tend to always not remember how declaration of in in loop behaves (though im not c newb for sure)

for(int i=0; i<10; i++)
{
int x = 10;
x++;
printf("\n %d", x);
}

for(int i=0; i<10; i++)
{
static int x = 10;
x++;
printf("\n %d", x);
}

those two behaves quite differently (though i test in c++ mode must say but i assume in standard c it is the same)

are you able to justify/explain the way it behaves is the right way?

fir <profesor.fir@gmail.com> writes:

> for(int i=0; i<10; i++)
> {
> int x = 10;
> x++;
> printf("\n %d", x);
> }
>
> for(int i=0; i<10; i++)
> {
> static int x = 10;
> x++;
> printf("\n %d", x);
> }
>
> those two behaves quite differently (though i test in c++ mode must
> say but i assume in standard c it is the same)
>
> are you able to justify/explain the way it behaves is the right way?

A declaration introduces a name. When declared inside a block, that
names is in scope (i.e. can be used) from the declaration to the end of
the block.

A definition, in contrast, creates an object (C's term for some area of
memory that can store values), usually associated with a name because all
definitions are declarations.

Objects have a storage duration. There are four storage durations, but
two matter here: automatic and static. Objects with automatic storage
duration are created when execution reaches the definition and ends when
execution exits the enclosing block. So in your first example, each
time round the loop a new object is created and named x. The
initialisation also happens each time round the loop.

Objects with static storage duration exist from the start of program
execution to the end of program execution and are initialised only once
at program start-up. So in your second look, x names an object that was
created and initialised before the loop was even executed for the first
time.

I make not claims that this justifies anything.

--
Ben.

sobota, 23 kwietnia 2022 o 03:22:18 UTC+2 Ben napisał(a):
> fir <profes...@gmail.com> writes:
>
> > for(int i=0; i<10; i++)
> > {
> > int x = 10;
> > x++;
> > printf("\n %d", x);
> > }
> >
> > for(int i=0; i<10; i++)
> > {
> > static int x = 10;
> > x++;
> > printf("\n %d", x);
> > }
> >
> > those two behaves quite differently (though i test in c++ mode must
> > say but i assume in standard c it is the same)
> >
> > are you able to justify/explain the way it behaves is the right way?
> A declaration introduces a name. When declared inside a block, that
> names is in scope (i.e. can be used) from the declaration to the end of
> the block.
>
> A definition, in contrast, creates an object (C's term for some area of
> memory that can store values), usually associated with a name because all
> definitions are declarations.
>
> Objects have a storage duration. There are four storage durations, but
> two matter here: automatic and static. Objects with automatic storage
> duration are created when execution reaches the definition and ends when
> execution exits the enclosing block. So in your first example, each
> time round the loop a new object is created and named x. The
> initialisation also happens each time round the loop.
>
> Objects with static storage duration exist from the start of program
> execution to the end of program execution and are initialised only once
> at program start-up. So in your second look, x names an object that was
> created and initialised before the loop was even executed for the first
> time.
>
> I make not claims that this justifies anything.
>
ok i should maybe name it definition i guess.. (i name such things often declaration as i understand
it as declare existence of int x here)

well what you say are some 'rules' but the rules are not stated authoritarly but come from some
reasons so i more asked if someone can justify the reasons why is that so ...besides the talk
that {} block in for loop closes and opens each turn of the loop is not convincing imo ..imo its rather more logical to see that this block opens before all turns/loop rotations and then close

hovever i will not state what i think on it personally yet, as im not quite fully sure yet

On 4/22/2022 5:42 PM, fir wrote:
> are you able to justify/explain the way it behaves is the right way?

Um... Their behavior is trivially explained by rather boring normal
everyday rules. Nothing remarkable here. Why the the question?

--
Best regards,
Andrey Tarasevich

On 4/22/2022 6:43 PM, fir wrote:

> ok i should maybe name it definition i guess.. (i name such things often declaration as i understand
> it as declare existence of int x here)

It is normal practice to use the term "declaration" everywhere,
including situations when the declaration in question is actually a
definition.

The only contexts when the term "definition" is used is usually where
you need to emphasize the fact this is a _defining_ declaration - a
definition.

That's the terminological approach used by the Standard, for one example.

> well what you say are some 'rules' but the rules are not stated authoritarly but come from some
> reasons so i more asked if someone can justify the reasons why is that so ..besides the talk
> that {} block in for loop closes and opens each turn of the loop is not convincing imo ..imo its rather more logical to see that this block opens before all turns/loop rotations and then close

Um... The body of the loop has no exclusive loop-specific properties.
When the body of the loop is expressed by a compound statement (a block,
a `{...}`) it has the same properties as compound statement anywhere
else. It begins at `{` and it ends at `}`. All local automatic objects
disappear at `}`. There's no carry-over behavior of any kind granted to
loop bodies just because they are loop bodies. They are regular compound
statements, obeying regular rules. They end after every iteration and
begin anew at the next iteration.

--
Best regards,
Andrey Tarasevich

sobota, 23 kwietnia 2022 o 04:20:40 UTC+2 Andrey Tarasevich napisał(a):
> On 4/22/2022 5:42 PM, fir wrote:
> > are you able to justify/explain the way it behaves is the right way?
> Um... Their behavior is trivially explained by rather boring normal
> everyday rules. Nothing remarkable here. Why the the question?
>
what noring normal everyday rules?

question is as i said: for me personally some decisions in language, like how this
above syntax constructs will behave need to be 'justified' by some reason stating
why this is right decision (some may say that i value rationale over the rules
just written - for me it is obvious that rules (language decisions) needs to be justfied/defended that they are right and that other decisions are not more reasonable)

i not thinked yet what i think on thois case but probably those decisions here may be doubtfull for me,
for example i could defend somewhat that imo it should be both 11 12 13 14... or also could defent that both could/shuld be 11 11 11 11..

sobota, 23 kwietnia 2022 o 04:47:33 UTC+2 fir napisał(a):
> sobota, 23 kwietnia 2022 o 04:20:40 UTC+2 Andrey Tarasevich napisał(a):
> > On 4/22/2022 5:42 PM, fir wrote:
> > > are you able to justify/explain the way it behaves is the right way?
> > Um... Their behavior is trivially explained by rather boring normal
> > everyday rules. Nothing remarkable here. Why the the question?
> >
> what noring normal everyday rules?
>
> question is as i said: for me personally some decisions in language, like how this
> above syntax constructs will behave need to be 'justified' by some reason stating
> why this is right decision (some may say that i value rationale over the rules
> just written - for me it is obvious that rules (language decisions) needs to be justfied/defended that they are right and that other decisions are not more reasonable)
>
> i not thinked yet what i think on thois case but probably those decisions here may be doubtfull for me,
> for example i could defend somewhat that imo it should be both 11 12 13 14.. or also could defent that both could/shuld be 11 11 11 11..

the arguments i may mention:
1) its weird that adding static drasticaly changes code flow (in fact i was not even clearly aware of that ) i find it rather bad
2) from some point initialisation should initialise only once so in both cases there should be 11 12 13 14..
if no you would need to put initialisation outside loop and its often good to keep declarations close
3) hovever in some cases i could find int x = 10 working this way that it both declares and restets to 10 in each loop also handy (i dont need to write int x; x = 10;)

finally i am not sure, there is also an option
to use syntax like
int x{10} = 2;
where {10} is initialisation and =2 is assigment (it may look idiotic here but this = for initialisation is confusing)
conservatives could say that int x = {10}; could stand for once a loop initialisation and int x = 10,
each turn 'reset'

On 4/22/2022 8:33 PM, fir wrote:
> sobota, 23 kwietnia 2022 o 04:47:33 UTC+2 fir napisał(a):
>> sobota, 23 kwietnia 2022 o 04:20:40 UTC+2 Andrey Tarasevich napisał(a):
>>> On 4/22/2022 5:42 PM, fir wrote:
>>>> are you able to justify/explain the way it behaves is the right way?
>>> Um... Their behavior is trivially explained by rather boring normal
>>> everyday rules. Nothing remarkable here. Why the the question?
>>>
>> what noring normal everyday rules?
>>
>> question is as i said: for me personally some decisions in language, like how this
>> above syntax constructs will behave need to be 'justified' by some reason stating
>> why this is right decision (some may say that i value rationale over the rules
>> just written - for me it is obvious that rules (language decisions) needs to be justfied/defended that they are right and that other decisions are not more reasonable)
>>
>> i not thinked yet what i think on thois case but probably those decisions here may be doubtfull for me,
>> for example i could defend somewhat that imo it should be both 11 12 13 14.. or also could defent that both could/shuld be 11 11 11 11..
>
> the arguments i may mention:
> 1) its weird that adding static drasticaly changes code flow (in fact i was not even clearly aware of that ) i find it rather bad

O_o

Adding `static` is inherently quite drastic. It drastically affects
storage duration and lifetime.

> 2) from some point initialisation should initialise only once so in both cases there should be 11 12 13 14..

It does initialize only once. Once per lifetime.

--
Best regards,
Andrey Tarasevich

fir <profesor.fir@gmail.com> wrote:

> 1) its weird that adding static drasticaly changes code flow (in fact i was not even clearly aware of that ) i find it rather bad
> 2) from some point initialisation should initialise only once so in both cases there should be 11 12 13 14..

fir, you're writing C for more than I can remember, and you still lack the
understanding of basic language constructs. This is sad.

--
The world is disgracefully managed; one hardly knows to whom to
complain.

fir <profesor.fir@gmail.com> wrote:

> ok i should maybe name it definition i guess.. (i name such things often
> declaration as i understand it as declare existence of int x here)

A declaration might declare the existence, but the existence might be
actually brought to life (defined) elsewhere. That's the difference.

> well what you say are some 'rules' but the rules are not stated
> authoritarly but come from some reasons so i more asked if someone can
> justify the reasons why is that so

Because that's how the static keyword works in this context. It's about
the scope of the variable and whether or not it retains its value.

https://www.geeksforgeeks.org/static-variables-in-c/

--
Never play leapfrog with a unicorn.

Am 23.04.2022 um 02:42 schrieb fir:
> may seem funny but i tend to always not remember how declaration of in in loop behaves (though im not c newb for sure)
>
> for(int i=0; i<10; i++)
> {
> int x = 10;
> x++;
> printf("\n %d", x);
> }
>
> for(int i=0; i<10; i++)
> {
> static int x = 10;
> x++;
> printf("\n %d", x);
> }

The only problem with the latter code is that it isn't thread-safe.
Better use thread_local. Aside from that both codes are identical.

sobota, 23 kwietnia 2022 o 06:52:56 UTC+2 Arnold Ziffel napisał(a):
> fir <profes...@gmail.com> wrote:
>
> > 1) its weird that adding static drasticaly changes code flow (in fact i was not even clearly aware of that ) i find it rather bad
> > 2) from some point initialisation should initialise only once so in both cases there should be 11 12 13 14..
> fir, you're writing C for more than I can remember, and you still lack the
> understanding of basic language constructs. This is sad.
>
maybe for you..for me its rather funny

sobota, 23 kwietnia 2022 o 12:37:08 UTC+2 fir napisał(a):
> sobota, 23 kwietnia 2022 o 06:52:56 UTC+2 Arnold Ziffel napisał(a):
> > fir <profes...@gmail.com> wrote:
> >
> > > 1) its weird that adding static drasticaly changes code flow (in fact i was not even clearly aware of that ) i find it rather bad
> > > 2) from some point initialisation should initialise only once so in both cases there should be 11 12 13 14..
> > fir, you're writing C for more than I can remember, and you still lack the
> > understanding of basic language constructs. This is sad.
> >
> maybe for you..for me its rather funny
i wouldnt say its a lack of understanding though, its rather a lack of remembering, some things i rarely use i may check before using but i am able to forget it again

sobota, 23 kwietnia 2022 o 08:20:01 UTC+2 Christian Hanné napisał(a):
> Am 23.04.2022 um 02:42 schrieb fir:
> > may seem funny but i tend to always not remember how declaration of in in loop behaves (though im not c newb for sure)
> >
> > for(int i=0; i<10; i++)
> > {
> > int x = 10;
> > x++;
> > printf("\n %d", x);
> > }
> >
> > for(int i=0; i<10; i++)
> > {
> > static int x = 10;
> > x++;
> > printf("\n %d", x);
> > }
> The only problem with the latter code is that it isn't thread-safe.
> Better use thread_local. Aside from that both codes are identical.

im not writing multi-threaded code, i think such kind of coding is not-elegant

if some want paralelistation it would be better to paralellize
critical loops (so called kernels)

arnold@hooterville.invalid (Arnold Ziffel) writes:

> fir <profesor.fir@gmail.com> wrote:

>> well what you say are some 'rules' but the rules are not stated
>> authoritarly but come from some reasons so i more asked if someone can
>> justify the reasons why is that so
>
> Because that's how the static keyword works in this context. It's about
> the scope of the variable and whether or not it retains its value.

static affects lifetime, not scope. Lifetime is a dynamic property of
objects, scope is a static property of names.

> https://www.geeksforgeeks.org/static-variables-in-c/

Who writes these things?

--
Ben.

fir <profesor.fir@gmail.com> writes:

> well what you say are some 'rules' but the rules are not stated
> authoritarly but come from some reasons so i more asked if someone can
> justify the reasons why is that so

Yes, I knew that's what you were asking but I've been on Usenet long
enough to know that there would be no point in my addressing it.
Instead, your question seemed to be a good place to comment on the all
too common confusion between scope and lifetime.

--
Ben.

sobota, 23 kwietnia 2022 o 13:43:26 UTC+2 Ben napisał(a):
> arn...@hooterville.invalid (Arnold Ziffel) writes:
> > fir <profes...@gmail.com> wrote:
>
> >> well what you say are some 'rules' but the rules are not stated
> >> authoritarly but come from some reasons so i more asked if someone can
> >> justify the reasons why is that so
> >
> > Because that's how the static keyword works in this context. It's about
> > the scope of the variable and whether or not it retains its value.
> static affects lifetime, not scope. Lifetime is a dynamic property of
> objects, scope is a static property of names.
>

here for me, its not a matter of 'storage' (lifetime) this is if it is static
imo this is more about expression becouse int a = 1; (or static int a = 1;)
is expression, and some constricts in c are meant to be usefull and it is more
better to be more usefull than less

in fact the main usabiulity of this above expression is in facty that it initialises
variable - and in fact if see this way int x = 1; initialises int static int x = 1; also initialises
hovever if so the behaviour of "int x = 10" when it restets each time to 10 its probably
wrong (seeint it this way)

it hovever as i already said it has this side effect that sometiumes you just write
int x = 10; instead of int x = 10; x = 10; when you want this.. at the moment i could say
that in a context of c in my opinion it could be

for(int i=0;i<10;i++) {
int x = {10}; printf("\n %d",x); // 10 11 12 13....
int y =10; printf("\n %d",y); // 10 10 10 10....
static int z = {10}; printf("\n %d", z); // 10 11 12 13....
static int w= 10; printf("\n %d",w); // 10 10 10 10....
x++; y++; z++;w++;
}

for me it would be more logical, but this is only my opinion..
and if someone wouldnt wont to add this = {} syntax and stay only with

int x = 10;
static int x = 10;
then in that case it boiuth imp probably would better give 10 11 12 13...

> > https://www.geeksforgeeks.org/static-variables-in-c/
>
> Who writes these things?
>

sobota, 23 kwietnia 2022 o 13:49:32 UTC+2 Ben napisał(a):
> fir <profes...@gmail.com> writes:
>
> > well what you say are some 'rules' but the rules are not stated
> > authoritarly but come from some reasons so i more asked if someone can
> > justify the reasons why is that so
> Yes, I knew that's what you were asking but I've been on Usenet long
> enough to know that there would be no point in my addressing it.
> Instead, your question seemed to be a good place to comment on the all
> too common confusion between scope and lifetime.
>
sure, anybody says what he wants...
i only state a question to gave oportunity for people
who wants to say on this to say what they want ,

On 23/04/2022 05:52, Arnold Ziffel wrote:
> fir, you're writing C for more than I can remember, and you still lack the
> understanding of basic language constructs. This is sad.
>
When people say they have been programming for xx number of years then
you know that they have passed their best!

A young person is likely to try something new all the time and he is
also likely to be thinking about the problem and possible improvements
all the time while an experienced person will simply say "I know it, I
have been programming for 30 years! Don't tell me how to do it".

Tech companies will hire a younger person more than someone who has been
programming for 30 years. It has nothing to do with pay structure; It is
to do with attitude of the so called experienced person.

On 4/23/22 8:12 AM, fir wrote:
> sobota, 23 kwietnia 2022 o 13:43:26 UTC+2 Ben napisał(a):
>> arn...@hooterville.invalid (Arnold Ziffel) writes:
>>> fir <profes...@gmail.com> wrote:
>>
>>>> well what you say are some 'rules' but the rules are not stated
>>>> authoritarly but come from some reasons so i more asked if someone can
>>>> justify the reasons why is that so
>>>
>>> Because that's how the static keyword works in this context. It's about
>>> the scope of the variable and whether or not it retains its value.
>> static affects lifetime, not scope. Lifetime is a dynamic property of
>> objects, scope is a static property of names.
>>
>
> here for me, its not a matter of 'storage' (lifetime) this is if it is static
> imo this is more about expression becouse int a = 1; (or static int a = 1;)
> is expression, and some constricts in c are meant to be usefull and it is more
> better to be more usefull than less
>
> in fact the main usabiulity of this above expression is in facty that it initialises
> variable - and in fact if see this way int x = 1; initialises int static int x = 1; also initialises
> hovever if so the behaviour of "int x = 10" when it restets each time to 10 its probably
> wrong (seeint it this way)
>
> it hovever as i already said it has this side effect that sometiumes you just write
> int x = 10; instead of int x = 10; x = 10; when you want this.. at the moment i could say
> that in a context of c in my opinion it could be
>
> for(int i=0;i<10;i++) {
> int x = {10}; printf("\n %d",x); // 10 11 12 13....
> int y =10; printf("\n %d",y); // 10 10 10 10....
> static int z = {10}; printf("\n %d", z); // 10 11 12 13....
> static int w= 10; printf("\n %d",w); // 10 10 10 10....
> x++; y++; z++;w++;
> }
>
> for me it would be more logical, but this is only my opinion..
> and if someone wouldnt wont to add this = {} syntax and stay only with
>
> int x = 10;
> static int x = 10;
> then in that case it boiuth imp probably would better give 10 11 12 13...
>
>

The key difference between

int x = 10;

and

int x;
x = 10;

is that the first INITIALIZES x when it is created, and the second
ASSIGNS it when the statement is executed.

When we change that to

static int x = 10;

Then by the rules of the C language, that initialization will only
happen the first time that we reach that statement, as after that the
variable has already been created, so it isn't initiialized again.

In fact, behind the scenes, there needs to be some other hidden flag
created by the implementation to know if initialization has happened.

Another way to look at it, if we look at C++ (which makes things more
explicit here) and use a user defined type:

Foo x = 10;

will use the constructor Foo(int) to create the variable, while:

Foo x;
x = 10;

Will first use the default constructor Foo() to create the variable, and
then Foo::operator =(int) to assign the value to the created variable.

(and if that isn't available use Foo(int) to make a temporary, and then
Foo::operator=(Foo&&) to assign the value).

On Saturday, April 23, 2022 at 2:43:51 AM UTC+1, fir wrote:
> sobota, 23 kwietnia 2022 o 03:22:18 UTC+2 Ben napisał(a):
> > fir <profes...@gmail.com> writes:
> >
> > > for(int i=0; i<10; i++)
> > > {
> > > int x = 10;
> > > x++;
> > > printf("\n %d", x);
> > > }
> > >
> > > for(int i=0; i<10; i++)
> > > {
> > > static int x = 10;
> > > x++;
> > > printf("\n %d", x);
> > > }
> > >
> > > those two behaves quite differently (though i test in c++ mode must
> > > say but i assume in standard c it is the same)
> > >
> > > are you able to justify/explain the way it behaves is the right way?
> > A declaration introduces a name. When declared inside a block, that
> > names is in scope (i.e. can be used) from the declaration to the end of
> > the block.
> >
> > A definition, in contrast, creates an object (C's term for some area of
> > memory that can store values), usually associated with a name because all
> > definitions are declarations.
> >
> > Objects have a storage duration. There are four storage durations, but
> > two matter here: automatic and static. Objects with automatic storage
> > duration are created when execution reaches the definition and ends when
> > execution exits the enclosing block. So in your first example, each
> > time round the loop a new object is created and named x. The
> > initialisation also happens each time round the loop.
> >
> > Objects with static storage duration exist from the start of program
> > execution to the end of program execution and are initialised only once
> > at program start-up. So in your second look, x names an object that was
> > created and initialised before the loop was even executed for the first
> > time.
> >
> > I make not claims that this justifies anything.
> >
> ok i should maybe name it definition i guess.. (i name such things often declaration as i understand
> it as declare existence of int x here)
>
> well what you say are some 'rules' but the rules are not stated authoritarly but come from some
> reasons so i more asked if someone can justify the reasons why is that so ..besides the talk
> that {} block in for loop closes and opens each turn of the loop is not convincing imo ..imo its rather more logical to see that this block opens before all turns/loop rotations and then close
>

Just think of it as FOR parameters DO command

Each time the paramters tell FOR to execute the command

In this case the command is a BLOCK so the block is executed
again and again for each iteration of the FOR loop.

You can have a BLOCK anywhere you have a command like several other
languages.

Also this is useful for extra temporary variables
if you wanted to partition them

int a,b;
puts("hello there");
a=14; b=17;
{int t; t=a; a=b; b=t; }

Also you can do many useful things using static variables
in a block

REGARDS LF
> hovever i will not state what i think on it personally yet, as im not quite fully sure yet

On Sat, 23 Apr 2022 13:26:56 -0400, Richard Damon
<Richard@Damon-Family.org> wrote:

>The key difference between
>
>int x = 10;
>
>and
>
>int x;
>x = 10;
>
>is that the first INITIALIZES x when it is created, and the second
>ASSIGNS it when the statement is executed.
>
>When we change that to
>
>static int x = 10;
>
>Then by the rules of the C language, that initialization will only
>happen the first time that we reach that statement, as after that the
>variable has already been created, so it isn't initiialized again.
>
>In fact, behind the scenes, there needs to be some other hidden flag
>created by the implementation to know if initialization has happened.

I disagree. Paragraph 5.1.2 of C11 explicitly states that a static
variable is initialized prior to program start up.

The key difference between "int x" (or "int x=10") and "static int x"
(with or without explicit initialization) is that during execution the
former causes the variable to be created (and initialized if
specified) while the latter does absolutely nothing since the variable
has already been created and initialized.

A hidden flag is not needed at all.

--
Remove del for email

fir <profesor.fir@gmail.com> wrote:

> i wouldnt say its a lack of understanding though, its rather a lack of
> remembering, some things i rarely use i may check before using but i am
> able to forget it again

You have to get more sleep to improve your memory...

--
An expert is one who knows more and more about less and less until he
knows absolutely everything about nothing.

On 23/04/2022 20:49, Barry Schwarz wrote:
> while the latter does absolutely nothing since the variable
> has already been created and initialized.
>
>
In other words no memory is allocated at this stage.

On Saturday, 23 April 2022 at 01:43:00 UTC+1, fir wrote:
> may seem funny but i tend to always not remember how declaration of in in loop behaves (though im not c newb for sure)
>
> for(int i=0; i<10; i++)
> {
> int x = 10;
> x++;
> printf("\n %d", x);
> }
>
> for(int i=0; i<10; i++)
> {
> static int x = 10;
> x++;
> printf("\n %d", x);
> }
>
> those two behaves quite differently (though i test in c++ mode must say but i assume in standard c it is the same)
>
> are you able to justify/explain the way it behaves is the right way?

Inside a function:

int x = 10; // initialised to 10 each time it is encountered (eg. per loop)

static int x = 10; // initialised to 10 at load-time (actually, set in .data section of exe)

If this was written with my syntax, it would clearer as the first is written using `x := 10`, and the second using `x = 10`. `:=` means a runtime assignment. `=` is taken care at compile-time/load-time.