"" and Nothing

  • Thread starter Thread starter Guest
  • Start date Start date
All you are showing here is the value ASSOCIATED with X, the IL doesn't show
us what is happening in the memory blocks. Looking at this in IL doesn't
show us anything we couldn't see in VB.NET.

We all agree that X will return a zero value after setting it to nothing,
what I'm saying is that when X is accessed after setting it equal to
nothing, the REASON we get zero is because this is a NEW X that hasn't been
initialized yet. The OLD X remains in memory, but is not accessible.
 
See earlier reply. Looking at this in IL doesn't tell us about the memory
address, only the value.
 
Scott M. said:
See earlier reply. Looking at this in IL doesn't tell us about the memory
address, only the value.

This wasn't IL, it was a section of native code (Assembly) compiled from
the VB commands:

Dim x As Integer
x = 10
x = Nothing
x = 20
x = 0

Loads 10 into the memory register esi

Clears the memory register esi

Loads 20 into the memory register esi

Clears the memory register esi


Earlier reply:
All you are showing here is the value ASSOCIATED with X, the IL doesn't show
us what is happening in the memory blocks. Looking at this in IL doesn't
show us anything we couldn't see in VB.NET.

We all agree that X will return a zero value after setting it to nothing,
what I'm saying is that when X is accessed after setting it equal to
nothing, the REASON we get zero is because this is a NEW X that hasn't been
initialized yet. The OLD X remains in memory, but is not accessible.

As shown above, X was assigned four values, including Nothing. There
was no code compiled that indicated anything about the destruction or
creation of anything else in memory. You indicate that after being set to
Nothing, X needs to be re-created to be accessed again. Where in the
above code is that happening? Since the above code in the native language
of the CPU, if it isn't happening there, it just isn't happening....

If we move x out to the module level, the code has to access the 'memory blocks'
there, and similar code is created:

x = 10
0000000d mov dword ptr [esi+000000F0h],0Ah
x = Nothing
00000017 mov dword ptr [esi+000000F0h],0
x = 20
00000021 mov dword ptr [esi+000000F0h],14h
x = 0
0000002b mov dword ptr [esi+000000F0h],0


But again, X = Nothing and X = 0 generate the exact same machine language
code. There is no code generated to destroy or create any new variable
reference. Knowing the New keyword is not used with value types, why
would you think that a new value type needed to be created?

???
LFS
 
The reason you get back "" is that after setting the string to Nothing and
then accessing it again, the object variable is not able to access the SAME
object in memory that was available before the object was set to Nothing.
Ressurection occurs and the NEW object variable, never having been
initialized, takes on the type's default value. The ORIGINAL object is not
affected.

No, that's just not so. There's no "resurrection" taking place. And
there is no NEW object. The reference to the old object has been set to
Nothing and the old object itself may or may not have been garbage
collected. The reference represented by 's' now points nowhere valid.

The only thing you're seeing is that VB.Net special-cases the '='
operator for strings, which treats Nothing as somewhat equivalent to
string.empty. This may appear at first sight to resemble a new object
with a default value, but it isn't, as seen by the fact that you can't
access any properties that 's' has after it has been set to Nothing.
 
Cor,

Cor Ligthert said:
???

Do you really mean this?

Yes, in the special case of the 'String' datatype, which is a reference
type! In this case, assigning 'Nothing' (or "setting the string variable's
value to 'Nothing'") will indeed make the variable containing a null
reference (a reference to 'Nothing') and not contain an empty string.
 
David said:
No, that's just not so. There's no "resurrection" taking place. And
there is no NEW object. The reference to the old object has been set to
Nothing and the old object itself may or may not have been garbage
collected. The reference represented by 's' now points nowhere valid.

The only thing you're seeing is that VB.Net special-cases the '='
operator for strings, which treats Nothing as somewhat equivalent to
string.empty. This may appear at first sight to resemble a new object
with a default value, but it isn't, as seen by the fact that you can't
access any properties that 's' has after it has been set to Nothing.

I couldn't have explained that better! Notice that only the '='
/comparison/ operator has this special behavior, not the '=' assignment
operator, which will truly assign a null reference.
 
Larry,

Larry Serflaten said:
But again, X = Nothing and X = 0 generate the exact same machine language
code. There is no code generated to destroy or create any new variable
reference. Knowing the New keyword is not used with value types, why
would you think that a new value type needed to be created?

'New' is optional for value types, except when calling a value type's
parameterized constructor. So, 'New' is /not/ an indicator for a type being
a value type! In other words, 'New' doesn't say anything about references,
it only says that a new object/value is created.

Where the value is stored and/or if the variable is placed on another
position is an implementation detail which it's not worth to worry about,
except when dealing with unsafe pointers to variables, which is rarely the
case within VB.NET code.
 
Cor,

Cor Ligthert said:
I showed it in relation to your text and there it is realy
xx as String = nothing, default which mean default value.

That that is for a string "" makes that this mostly is done with "" which
I find nicer by the way.

'Dim s As String' is the same as 'Dim s As String = Nothing', but it's
different from 'Dim s As String = ""', which is the same as 'Dim s As String
= String.Empty'.

In most brains, strings are a value type and VB.NET tries to make value type
semantics available for .NET's 'String' reference type. VB.NET's functions
like 'Len', for example, treat a null reference like a zero-length string.
 
Very interesting.

Herfried K. Wagner said:
I couldn't have explained that better! Notice that only the '='
/comparison/ operator has this special behavior, not the '=' assignment
operator, which will truly assign a null reference.
 
(Inline)

Herfried K. Wagner said:
'New' is optional for value types, except when calling a value type's
parameterized constructor. So, 'New' is /not/ an indicator for a type being
a value type!

Where did I say it was an indicator? I simply said it wasn't used for value
types. You seem to say I said New was not allowed, but read it again, I
simply said it was not used. Perhaps that would have been better said, 'New
is not commonly used ...' but I didn't think I would need to elaborate!
Where the value is stored and/or if the variable is placed on another
position is an implementation detail which it's not worth to worry about,

What does that mean? Are you trying to say that the machine code does not
indicate how variables are treated? If that is it, I'd have to differ, if it doesn't
happen at the machine code level, then it doesn't get done....

What I showed indicated that there was no code executed that either destroyed
or created a reference, as was indicated by Scott's statement:

What I posted indicated that X=Nothing was identical to X=0, and thus, no
destruction took place.

Investigating further shows that using New on a value type does have an
adverse effect (MSIL and Assmbly):

//000046: Dim a As Integer
//000047: a = Nothing
IL_0001: ldc.i4.0
IL_0002: stloc.0
//000048: a = 0
IL_0003: ldc.i4.0
IL_0004: stloc.0
//000049:
//000050: Dim b As New Integer
IL_0005: ldloca.s b
IL_0007: initobj [mscorlib]System.Int32
//000051: b = Nothing
IL_000d: ldc.i4.0
IL_000e: stloc.1
//000052: b = 0
IL_000f: ldc.i4.0
IL_0010: stloc.1


00000007 xor eax,eax
00000009 mov dword ptr [ebp-10h],eax
0000000c mov dword ptr [ebp-4],ecx
0000000f mov dword ptr [ebp-8],edx
00000012 xor esi,esi
00000014 nop
a = Nothing
00000015 xor esi,esi
a = 0
00000017 xor esi,esi
Dim b As New Integer
00000019 mov dword ptr [ebp-10h],0
b = Nothing
00000020 mov dword ptr [ebp-10h],0
b = 0
00000027 mov dword ptr [ebp-10h],0


Even while using New adds a level of indirection, it still shows that
setting a value type to Nothing is 'exactly the same' as assigning a
value of 0. No one would try to claim that assigning a value of 0
causes the variable to be destroyed, would they?

LFS
 
Herfried,

In this case was I talking about all value types except the String because
for that was an extra row. The String has in my opinion confusing rules
thinking about constants and variables. Not that that is very important,
because it acts always as a value.

Quoute me complete please as I forever say, now it looks if I wrote
something else and you know what I think about this kind of quoting.

Cor
 
Larry,

Larry Serflaten said:
Where did I say it was an indicator? I simply said it wasn't used for
value
types. You seem to say I said New was not allowed, but read it again, I
simply said it was not used. Perhaps that would have been better said,
'New
is not commonly used ...' but I didn't think I would need to elaborate!

I didn't want to criticise what you say! I just thought that your last
sentence kept something open, which I described.
What does that mean? Are you trying to say that the machine code does not
indicate how variables are treated?

No, I don't mean that. What I wanted to say is that it's completely
transparent to the programmer where the variable's content is stored. It
can be either stored in-place or a pointer pointing to it. In case of the
value types, it's stored on a certain position and overwritten.
What I showed indicated that there was no code executed that either
destroyed
or created a reference, as was indicated by Scott's statement:

.... and I agree on that.
Investigating further shows that using New on a value type does have an
adverse effect (MSIL and Assmbly):

//000046: Dim a As Integer
//000047: a = Nothing
IL_0001: ldc.i4.0
IL_0002: stloc.0
//000048: a = 0
IL_0003: ldc.i4.0
IL_0004: stloc.0
//000049:
//000050: Dim b As New Integer
IL_0005: ldloca.s b
IL_0007: initobj [mscorlib]System.Int32
//000051: b = Nothing
IL_000d: ldc.i4.0
IL_000e: stloc.1
//000052: b = 0
IL_000f: ldc.i4.0
IL_0010: stloc.1


00000007 xor eax,eax
00000009 mov dword ptr [ebp-10h],eax
0000000c mov dword ptr [ebp-4],ecx
0000000f mov dword ptr [ebp-8],edx
00000012 xor esi,esi
00000014 nop
a = Nothing
00000015 xor esi,esi
a = 0
00000017 xor esi,esi
Dim b As New Integer
00000019 mov dword ptr [ebp-10h],0
b = Nothing
00000020 mov dword ptr [ebp-10h],0
b = 0
00000027 mov dword ptr [ebp-10h],0


Even while using New adds a level of indirection, it still shows that
setting a value type to Nothing is 'exactly the same' as assigning a
value of 0. No one would try to claim that assigning a value of 0
causes the variable to be destroyed, would they?

Full ACK.
 
Back
Top