Variables initialization

[Чебурашка]

Hello,
please can someone indicate me where to find a "complete" view of the compiler feature "variables initialization logic", if such feature exists? Or simply this feature doesn't exist?

To explain this better:

Code: Pascal  [Select][+][-]

1. var
2.   i: Integer;
3. begin
4.   // i is initialized to a default yes, no, sometimes depending on the context, or if i is part of other structures like a record, object or class?
5.  

According to

https://www.freepascal.org/docs-html/current/ref/refse24.html#x55-750004.4

no initialization is done, but often I find values set to zero while debugging, even if I don't make any initialization, so is that by chance?

[440bx]

The "initialization" depends on _where_ the "var" statement is found.

if the "var" defines a _global_ variable or a "unit variable" (which is a global in a unit, which may or may not be interfaced) then the variable is initialized because it is (normally) located in the initialized data segment (that's what FPC normally does.) Normally those variables are zero (binary zeroes which normally translates to a "normal" zero.)

if the "var" defines a procedure/function/method _local_ variable then it is NOT initialized.  The variable will have whatever value is at the stack location it has been assigned by its offset from the frame pointer.  IOW, it's initial value is random.

NOTE: the above applies to how the compiler behaves under Windows, it is possible there might be slight differences in other platforms.

Good programming requires that if you want to ensure a variable is initialized then, it should be explicitly initialized and _not_ depend on compiler behavior which may vary from one platform to another.

HTH.

[ccrause]

Hello,
please can someone indicate me where to find a "complete" view of the compiler feature "variables initialization logic", if such feature exists? Or simply this feature doesn't exist?

To explain this better:

Code: Pascal  [Select][+][-]

1. var
2.   i: Integer;
3. begin
4.   // i is initialized to a default yes, no, sometimes depending on the context, or if i is part of other structures like a record, object or class?
5.  

According to

https://www.freepascal.org/docs-html/current/ref/refse24.html#x55-750004.4

no initialization is done, but often I find values set to zero while debugging, even if I don't make any initialization, so is that by chance?

I assume in the example above variable i is a global variable? Then it is covered by the second remark on the page you linked to above: "Global variables are initialized with the equivalent of zero".

[Чебурашка]

Thank you all for the notes!

In my case I wanted to have a "complete" view of this feature because I was in trouble with a variable part of a class definition (in my case was a Pointer).

Code: Pascal  [Select][+][-]

1.  
2.   TMyClass = class(TObject)
3.   private
4.     FPdata: Pointer;
5.  
6. constructor TMyClass.Create(Apdata: Pointer; Alength: Integer);
7. begin
8.   inherited Create();
9.  
10.   if ((Apdata <> nil) and (Alength > 0)) then
11.   begin
12.     FPdata := GetMem(Alength);
13.     Move(Apdata^, FPdata^, Alength);
14.   end;
15.   // what if branch is not executed? how is FPdata set?
16. end;
17.  
18.  

[Чебурашка]

I fully agree that good programming practice recommends that certain operations like init are made explictely, without relying on compiler, but it is also true that if compiler makes it, and then I also do it manually, in situations where a portion of code is called at high frequency one can get duplicated operations and this can result in worst efficiency. This is why I was thinking to a "complete" view of the init feature was nice: I can see where init is always done by compiler and where is not done always.

[ASerge]

In my case I wanted to have a "complete" view of this feature because I was in trouble with a variable part of a class definition (in my case was a Pointer).

Inside the structure (class) these are already called fields, not variables. If we talk about ordinary classes, i.e. inherited from TObject, then all fields are zeroed when creating an instance, as indicated in TObject.NewInstance.

[440bx]

I also do it manually, in situations where a portion of code is called at high frequency one can get duplicated operations and this can result in worst efficiency.

Yes, it is possible to run into cases where the initialization results in a time penalty.

That said, keep in mind that, in today's machines, a simple constant assignment can often be done in the order of a billion times before it becomes humanly perceptible.  I believe in writing efficient code but, 1 billionth of a second is rarely something worth accounting for.  There are cases where such small expenditures of time can make a genuine difference but, those are rare.

HTH.

[Чебурашка]

In my case I wanted to have a "complete" view of this feature because I was in trouble with a variable part of a class definition (in my case was a Pointer).

Inside the structure (class) these are already called fields, not variables. If we talk about ordinary classes, i.e. inherited from TObject, then all fields are zeroed when creating an instance, as indicated in TObject.NewInstance.

Yes, in fact I now see that the field (i was calling it variable) that I was suspecting to mess up is actually not doing anything wrong.

[Чебурашка]

I also do it manually, in situations where a portion of code is called at high frequency one can get duplicated operations and this can result in worst efficiency.

Yes, it is possible to run into cases where the initialization results in a time penalty.

That said, keep in mind that, in today's machines, a simple constant assignment can often be done in the order of a billion times before it becomes humanly perceptible.  I believe in writing efficient code but, 1 billionth of a second is rarely something worth accounting for.  There are cases where such small expenditures of time can make a genuine difference but, those are rare.

HTH.

Sure is as you say, I was just thinking in general: if something is done by X (compiler) it should not be done also by Y (me) as I am doing an extra action, and is useless.

[Joanna]

I fully agree that good programming practice recommends that certain operations like init are made explictely, without relying on compiler, but it is also true that if compiler makes it, and then I also do it manually, in situations where a portion of code is called at high frequency one can get duplicated operations and this can result in worst efficiency. This is why I was thinking to a "complete" view of the init feature was nice: I can see where init is always done by compiler and where is not done always.

Your considerations are quite valid for consolidating redundant code when the code is your own, however the code in compiler that happens to initialize variables to 0 is not guaranteed. Something could change in the future or other conditions. Unfortunately writing robust code always takes more resources than brittle code but it’s worth it I think..

certain operations like init are made explictely

You probably meant explicitly 

[PascalDragon]

I fully agree that good programming practice recommends that certain operations like init are made explictely, without relying on compiler, but it is also true that if compiler makes it, and then I also do it manually, in situations where a portion of code is called at high frequency one can get duplicated operations and this can result in worst efficiency. This is why I was thinking to a "complete" view of the init feature was nice: I can see where init is always done by compiler and where is not done always.

Your considerations are quite valid for consolidating redundant code when the code is your own, however the code in compiler that happens to initialize variables to 0 is not guaranteed. Something could change in the future or other conditions. Unfortunately writing robust code always takes more resources than brittle code but it’s worth it I think..

For some things it is guaranteed, because it's considered part of the language. This includes:

• fields of classes as long as the default TObject.NewInstance is used
• managed types (strings, interfaces, dynamic arrays)
• global variables (it's been documented as such only recently however)
• thread variables

[440bx]

For some things it is guaranteed, because it's considered part of the language.

It may be part of FPC but it is not part of the Pascal language.

What I'm getting at is that Delphi and FPC may not initialize the same fields, therefore relying on such initialization has a negative effect on portability (mostly between Delphi and FPC, or vice versa, in this case.)

[Joanna]

I didn’t know that the fpc initializes things by default, I was once told that uninitialized variables could be anything!! by a pascal teacher long ago....
I guess much has changed with pascal 

[Weiss]

I didn’t know that the fpc initializes things by default, I was once told that uninitialized variables could be anything!! by a pascal teacher long ago....
I guess much has changed with pascal 

it is actually somewhere in tutorials too. I took it by heart since day one.

I fully agree that good programming practice recommends that certain operations like init are made explictely, without relying on compiler, but it is also true that if compiler makes it, and then I also do it manually, in situations where a portion of code is called at high frequency one can get duplicated operations and this can result in worst efficiency. This is why I was thinking to a "complete" view of the init feature was nice: I can see where init is always done by compiler and where is not done always.

Isn't it easier to design execution flow in such way that values assigned naturally with meaningful values before the first time the value is being used anywhere in program. Then there is no guessing or duplicate operations.

[Joanna]

it is actually somewhere in tutorials too. I took it by heart since day one.

It probably is but I’m too impatient to start programming to read the tutorials and books about object pascal even though I’m sure they are excellent. The last time I studied manuals was for turbo pascal 7 ...

Isn't it easier to design execution flow in such way that values assigned naturally with meaningful values before the first time the value is being used anywhere in program. Then there is no guessing or duplicate operations.

That’s a good idea to always do that, even if it is only to get rid of the uninitialized variable warnings. I initialize things as soon as they are created.