Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

rules of initialisation in loop (in c and in c+++)

45 views
Skip to first unread message

fir

unread,
Mar 7, 2019, 3:37:27 PM3/7/19
to
ould meyba someone remind me what are
rules of initialisation of variables whan it is in loop ?


i mean

for(;;)
{
Some x = {10, 20, 30};

}

will it be initialised each time or only once or will not compile (im not touching compiler now and cant check)

(not so long time ago i was stating some thread on close things (named "small c probem" but i tend to forgot such things)

and how it is in c++, where such obiect like here Some x would have destructor and construictor... afair c++ enforces that constructor and destrctor are called constantly (which in some way is sorta cretinic i belive), hovever in mentioned thread i see i wrote i made some test with
int initialized c++ way int a(10) and it was there working right way (right way imo is doing it only once for block, not for each loop turn

some hints?

Paavo Helde

unread,
Mar 7, 2019, 5:08:20 PM3/7/19
to
On 7.03.2019 22:37, fir wrote:
> ould meyba someone remind me what are
> rules of initialisation of variables whan it is in loop ?
>
>
> i mean
>
> for(;;)
> {
> Some x = {10, 20, 30};
>
> }
>
> will it be initialised each time or only once or will not compile (im not touching compiler now and cant check)

x is defined inside the for loop body so it is initialized and destroyed
on each iteration. This is a good thing (tm).

If you do not want this you can define x outside the loop, and only
assign to it inside the loop. This means two-stage initialization, which
is a bit problematic as it makes the things more complicated and
error-prone.

>
> (not so long time ago i was stating some thread on close things (named "small c probem" but i tend to forgot such things)
>
> and how it is in c++, where such obiect like here Some x would have destructor and construictor... afair c++ enforces that constructor and destrctor are called constantly (which in some way is sorta cretinic i belive), hovever in mentioned thread i see i wrote i made some test with
> int initialized c++ way int a(10) and it was there working right way (right way imo is doing it only once for block, not for each loop turn

Strictly pairing a constructor call with a destructor call is called
RAII, which is the strongest point of C++, ever. If you want this to
happen only once, you define x outside of the loop or as a static (if
appropriate).


fir

unread,
Mar 7, 2019, 7:09:10 PM3/7/19
to
ok
but this is not a good thing, its silly

old c has it right way it is if you put Some x; in a loop the stack pointer dont moves back and forth every loop turn as it would be silly

assigments in loop, ok , but initialisiation ? no, it is silly

(it is silly becouse every turn in a loop
you use the same variable so why destroing and re-creating it (it is silly as i already said), and if you want to re=set the value assigment is a way to go

James Kuyper

unread,
Mar 7, 2019, 7:11:27 PM3/7/19
to
On 3/7/19 17:08, Paavo Helde wrote:
...
> Strictly pairing a constructor call with a destructor call is called
> RAII, which is the strongest point of C++, ever. If you want this to
> happen only once, you define x outside of the loop or as a static (if
> appropriate).

RAII is an idiom, which in C++ can be implemented by relying upon the
pairing of constructor calls with destructor calls to acquire and
release the relevant resource. That pairing is not itself RAII.

An extreme counter-example would be a class that used the exact same
pairing to release a resource in the constructor, and reacquire it in
the destructor (obviously, the handle for any resource managed in that
fashion would not be stored in a non-static member variable).

I'm not saying that it would be reasonable to do so. I'm only using that
example to point out that it's only when you use that pairing in a
particular way that it implements RAII.


Alf P. Steinbach

unread,
Mar 8, 2019, 12:08:33 AM3/8/19
to
On 08.03.2019 01:09, fir wrote:
> W dniu czwartek, 7 marca 2019 23:08:20 UTC+1 użytkownik Paavo Helde napisał:
>> On 7.03.2019 22:37, fir wrote:
>>> ould meyba someone remind me what are
>>> rules of initialisation of variables whan it is in loop ?
>>>
>>>
>>> i mean
>>>
>>> for(;;)
>>> {
>>> Some x = {10, 20, 30};
>>>
>>> }
>>>
> [snip]
> old c has it right way it is if you put Some x; in a loop the stack
> pointer dont moves back and forth every loop turn as it would be
> silly
There is no need for a stack pointer adjustment.


Cheers & hth.,

- Alf

Paavo Helde

unread,
Mar 8, 2019, 12:55:59 AM3/8/19
to
On 8.03.2019 2:09, fir wrote:
> ok
> but this is not a good thing, its silly
>
> old c has it right way it is if you put Some x; in a loop the stack pointer dont moves back and forth every loop turn as it would be silly
>
> assigments in loop, ok , but initialisiation ? no, it is silly
>
> (it is silly becouse every turn in a loop
> you use the same variable so why destroing and re-creating it (it is silly as i already said), and if you want to re=set the value assigment is a way to go

You sound like thinking that destroying and re-creating were
automatically somehow more expensive than re-assignment.

However, C++ is not some kind of script language where destroying and
re-creating a variable would mean updating of some dynamic map.
Destroying and re-creation might well be non-ops in C++.

If the variable holds a resource like dynamically allocated memory or an
open file handle, it might indeed be more expensive to destroy and
re-create it all the time. On the other hand, leaving it undestroyed
would mean the resource is kept around for longer than needed. For
example, if iteration 0 requires a memory buffer of 100 MB and the rest
of the loop iterations require a memory buffer of 1 MB, then in case of
buffer reuse the unneeded 99 MB are unnecessarily held around for the
whole loop duration. If this might be a problem or not depends on the
situation. You cannot say that one way is automatically better than the
other.

Thankfully, C++ allows to use both ways as needed, after studying the
performance profiler results.

David Brown

unread,
Mar 8, 2019, 2:30:12 AM3/8/19
to
C and C++ do this in /exactly/ the same way.

>
> assigments in loop, ok , but initialisiation ? no, it is silly
>
> (it is silly becouse every turn in a loop
> you use the same variable so why destroing and re-creating it (it is silly as i already said), and if you want to re=set the value assigment is a way to go
>

C does this too.

But for both C and C++, the compiler can be smart about it. In neither
case will you see the stack pointer being moved up and down - compilers
combine stack pointer movements for efficiency.

In C++, if the variable "x" inside the loop is a simple type that
doesn't actually do anything in the constructor or destructor, then the
cost is zero. /Logically/ the variable is constructed and destructed,
but the generated code won't do more than necessary.

fir

unread,
Mar 8, 2019, 3:55:15 AM3/8/19
to
looking that loop goes out of block end enters each block each turn in the loop {}{}{}{}{} is posibly an error,
more apropriate would be to look at it that loop leaves block on break but not by continue (or default wind back/ next

if you want to resize wariable in loop you sementaically can just call some resize on it not destroint and recreating it

besides does you maybe know, or somebody
thet when you got (in C, primary sasking on C here)

struct Some {int x,t,z; };

for(;;)
{
Some x = { 10, 20, 30 };

}

is this line inside a loop considered always as an initialization or is it considered maybe as assigment / some combination of initialization and assigment

can you remind me if
for(;;)
{
x = { 10, 20, 30 };

}

works in c? im far from the compiler and cant check, and i dont remember

David Brown

unread,
Mar 8, 2019, 4:40:27 AM3/8/19
to
On 08/03/2019 09:55, fir wrote:
>
> besides does you maybe know, or somebody
> thet when you got (in C, primary sasking on C here)
>
> struct Some {int x,t,z; };
>
> for(;;)
> {
> Some x = { 10, 20, 30 };
>
> }
>
> is this line inside a loop considered always as an initialization or
> is it considered maybe as assigment / some combination of
> initialization and assigment
It is a definition and initialisation. As far as C is concerned, the
lifetime of "x" starts when the loop's block is entered, and ends when
the loop's block ends. Logically, "x" is created anew at the start of
the block (once per loop), then initialised anew with these values. At
the end of the loop, it is destroyed.

In C, "constructing" an automatic variable is usually no more than a
stack pointer change, or using a register. Initialisation is just
setting the data in the stack frame or the register. "Destruction" is
restoring the stack pointer. Initialisation and assignment of local
variables is generally identical - you don't see a difference between
"int x; x = 1;" and "int x = 1;" (except for const variables, and other
syntactic details).

In C++, objects can have more complicated constructors, destructors,
initialisation and assignment - but the principle is /exactly/ the same.

And in both cases, the compiler is free to optimise the code. Almost
invariably (when there are no VLA's or other big stack allocations),
compilers will do all necessary stack pointer manipulation in the
function prologue and epilogue, and not bother moving it up and down
within loops like this. This is identical for C and C++.


>
> can you remind me if
> for(;;)
> {
> x = { 10, 20, 30 };
>
> }
>
> works in c? im far from the compiler and cant check, and i dont remember
>

It works for initialisation, but not for assignment.


struct Some { int x, t, z; };

struct Some foo(void) {
struct Some x = {1, 2, 3}; // OK in C and C++
return x;
}

struct Some foo2(void) {
struct Some x;
x = (struct Some) {1, 2, 3}; // OK in C, not in C++
return x;
}

struct Some foo3(void) {
struct Some x;
x = {1, 2, 3}; // OK in C++11, not in C
return x;
}

(Compound literals as used in foo2 are in C99 and C11, but not in C++
except as compiler extensions - gcc allows them in C++, but I don't know
about other compilers.)

0 new messages