• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 266
  • Last Modified:

Variable initialization by compiler - clarification needed

D4 Help claims that *global* variables are automatically initialized to 0, whereas *local* variables contain random data until a value is assigned to them.

For *global* variables I presume this means...

integers initialized to 0
booleans initialized to false
strings  initialised to ''
pointers / object refs initialized to nil
Is this correct?

Also, I assume that private/public member fields of a class are considered *global* variables in this context and are therefore also intialized to 0.  Is this also correct?

Do *local* variables then refer only to variables declared within a procedure or function, whether it be a unit function or class member function.

Do any compiler or linker settings affect how variables are initialized (e.g. optimisation)?

Clarification please.

Thanks

Andrew

0
andrewjackson
Asked:
andrewjackson
1 Solution
 
TheNeilCommented:
To be safe, initialise everything yourself and don't trust the compiler one bit

The Neil
0
 
andrewjacksonAuthor Commented:
Yes, fair point, that is what I normally do.

However, I've trying to track down a bug which is very difficult to replicate.  I've found a private boolean variable in one of my classes which (by mistake) I've not initialised and which I suspect just might be the cause of the bug.  

It should be initialised to FALSE but if I manually initialise it to TRUE the bug occurs.  I want to establish if the compiler might every let that happen. However, all the testing I've done shows the compiler always initialising it to FALSE.  If that is the case then I will have to rule out this variable as the cause of my bug :(

Thanks anyway,

Regards

Andrew
0
 
JoeBoothCommented:
Add an assertion around the code where you expect the variable to be FALSE.  This way, the assertion will get triggered if the compiler does something funny, plus you'll be documenting the potential bug for other programmers (and yourself a year down the road)
0
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
andrewjacksonAuthor Commented:
Yes, I've tried that as part of my latest debugging effort but haven't been able to replicate the bug or trigger the assertion yet :( (The bug appears VERY occasionaly)

Also, the code forms part of a DCOM server. I can't really leave assertions in production or system testing code since an assertion or other message dialog popped-up by the server locks remote clients.

I just need clarifacation on what the compiler will or will not do with this variable when the object is instantiated so I can establish if its the cause of the bug.

Thanks anyway for you help

Andrew
0
 
MadshiCommented:
>> For *global* variables I presume this means...
>> integers initialized to 0
>> booleans initialized to false
>> strings  initialised to ''
>> pointers / object refs initialized to nil
>> Is this correct?

Exactly. BUT: They are initialized AFTER the initialization part of the unit was executed. So your code between "initialization ... end" must not rely on this.

>> Also, I assume that private/public member fields of a class are considered *global* variables in this context and are therefore also intialized to 0.  Is this also correct?

Yes.

>> Do *local* variables then refer only to variables declared within a procedure or function, whether it be a unit function or class member function.

Yes.

>> Do any compiler or linker settings affect how variables are initialized (e.g. optimisation)?

Optimization definetely not. I don't know, perhaps there's a hidden setting somewhere - but I don't know one.

Regards, Madshi.
0
 
MadshiCommented:
P.S:

strings, wide strings, interface variables (D3 or higher) and dynamic arrays (D4 or higher) are ALWAYS initialized to 0 (or nil or '') - even in such a complicated type:

procedure test;
type TComplicated = array of record
    str: string;
    anotherRecord: array of record
      str2: string;
      dynArr: array of array of string;
      int: integer;
    end;
  end;
var compl : TComplicated;
begin


Now you can rely on that all dynamic parts of this record are initialized to 0 (otherwise you would get exceptions when using them). The only part of the record that is in this example NOT initialized is "compl.anotherRecord.int".

Regards, Madshi.
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now