andrewjackson
asked on
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
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
ASKER
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
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
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)
ASKER
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
The Neil