When I found an incompatibility between our VO and X# versions of programs regarding initializing strings I looked further to the switch "Initialize strings" /vo2
It is interesting how many details may have influences when moving from Win32 to Dotnet.
I want to resume what I have found out (Surely Chris will tell if I am correct) switch has been set to on
- All strings initially are automatically filled with "": object variables within the constructor, local variables before execution of the first line
- Comparisons with null_string are changed internally to comparisons with ""
- So comparing a string with null_string or "" returns True
- Small disadvantage: object string variables initialized before calling the super constructor are emptied again by the first constructor. switch has been set to off
- All strings not initialized explicitly are null references to the string object
- Comparing a string "" with "" returns true and comparing with null_string returns false
- Comparing a null_string with "" returns false and comparing with null_string returns true
So it seems safe to set the switch to "On" if in an existing program there are many equal comparisons mixed with null_string and ""
in my eyes it is a small bug regarding the compatibility to VO.
According to Chris it isn't easy to modify this behavior and I can understand this. So I looked into our code and there shouldn't be too many places to change. More important is having the int variables being set.
I have added the test example below. In case of initializing a variable before calling the super constructor leaves the int variable as it had been set by the program whereas the string variable is set to an empty string.
protect _nRegArt as int
protect _cReportCaption as string
protect _cts as string
Just to be clear about this, only string vars/fields are affected by /vo2.
Numeric vars are _always_ initialized to zero by the CLR itself, our compiler/runtime has nothing to do with it. Well, that is at least in the windows implementation of .Net!