Is there a difference between passing "" and passing Nothing to a Windows API ?

  • Thread starter Thread starter academic
  • Start date Start date
A

academic

When I declare a reference variable I initialize it to Nothing.

Now I'm wondering if that best for String variables - is "" better?

With Nothing I assume no memory is set aside nor GC'ed

But with "" it is - correct?

The system seems to handle a null the same as "".

For example:

s=A & "more text" 'Works the same if A=Nothing or A=""

Does this run the same code?

What about passing to a Windows API?

Is there a difference between passing "" and passing Nothing?


Thank you
 
Is there a difference between passing "" and passing Nothing?

They are different. The simplest example of the difference is with
i = Len(s)
i = s.Length
s.Length will fail if s is nothing. Some vb string handling will work fine
(and identically) with "" and nothing. Generally, vb legacy string handling
copes with both, but object oriented functionality treats them differently.
FYI, my habit is to avoid Nothing with strings.
 
it is considered good coding practice to initialize string values with a
empty string value

dim x as string =""
or
dim x as string=string.empty


if you do not do this you should always use this

if not x is nothing then
' must check for nothing before processing
end if

regards

Michel Posseth [MCP]
 
But with "" it is - correct?

Yes. But that shouldn't stop you from using it if appropriate.

The system seems to handle a null the same as "".
Click to expand...

Depends on what you mean by "the system". The VB language and
libraries often tries to hide the difference but in the the .NET
framework there's usually a significant difference.

What about passing to a Windows API?

Is there a difference between passing "" and passing Nothing?
Click to expand...

Yes.


Mattias
 
it is considered good coding practice to initialize string values with a
empty string value
Click to expand...

It is? I would only do so if I had a good reason for it, not so I
could be lazy and skip proper null checking later on.


Mattias
 
m.posseth said:
it is considered good coding practice to initialize string values with a
empty string value

dim x as string =""
or
dim x as string=string.empty
Click to expand...
Are these equivalent

I mean, does x end up the same?

Thanks
 
AMercer said:
They are different. The simplest example of the difference is with
i = Len(s)
i = s.Length
s.Length will fail if s is nothing. Some vb string handling will work
fine
(and identically) with "" and nothing. Generally, vb legacy string
handling
copes with both, but object oriented functionality treats them
differently.
FYI, my habit is to avoid Nothing with strings.
Click to expand...

I going to make this my habit too. No reason not to - except with Windows
Api calls.

Thanks
 
Mattias Sjögren said:
It is? I would only do so if I had a good reason for it, not so I
could be lazy and skip proper null checking later on.
Click to expand...
I wonder why not - is there some reason to use Nothing and then check?
 
It is? I would only do so if I had a good reason for it, not so I
could be lazy and skip proper null checking later on.
Click to expand...

According to "practical guidelines and best practices for Microsoft Visual
Basic and Visual C# Developers"

so by Francesco Balena and Giusseppe Dimauro and MS Press it is :-)

Why :

Explicit assignment avoids NullReferenceException errors when referencing
the string and simplifies code ( because the string doesn`t have to be
tested against null )

note :

initializing this way points to the only zero length string that is
allocated in the string intern heap so it doesn`t waste memory as some
developers believe



regards

Michel Posseth [MCP]
 
Mattias Sjögren said:
Yes. But that shouldn't stop you from using it if appropriate.
Click to expand...
I can't think of a situation where it is appropriate ( which is not to imply
that I think there isn't any)
Depends on what you mean by "the system". The VB language and
libraries often tries to hide the difference but in the the .NET
framework there's usually a significant difference.
Click to expand...

That's explains a lot
Yes.
Click to expand...
I believe passing Nothing would cause a zero to be put on the stack.

What does pass "" do?



Thanks
 
m.posseth said:
According to "practical guidelines and best practices for Microsoft
Visual Basic and Visual C# Developers"

so by Francesco Balena and Giusseppe Dimauro and MS Press it is :-)

Why :

Explicit assignment avoids NullReferenceException errors when referencing
the string and simplifies code ( because the string doesn`t have to be
tested against null )
Click to expand...

Mhm... That's why I use 'Right', 'Left', 'Len', etc. if I do not want
exceptions to be thrown on string variables referencing 'Nothing'.

BTW: I do not think that initializing string variables to an empty
(zero-length) string is good practice too.
 
"" and string.empty are perfectly equivalant

prove ??


dim x as string =""
dim y as string = string.empty

string.ReferenceEquals(x,y)

this will display true


regards

Michel Posseth [MCP]
 
Mhm... That's why I use 'Right', 'Left', 'Len', etc. if I do not want
exceptions to be thrown on string variables referencing 'Nothing'.
Click to expand...

I did exactly that for the obvious same reassons ,,,

however i have recently changed my coding style
BTW: I do not think that initializing string variables to an empty
(zero-length) string is good practice too.
Click to expand...

We live in a free country ( well ,, i know you and i do :-) ) so you
can always do as you please

however fact is that this book is written by the author of all the
programming microsoft visual basic core references
( 6 , 2002, 2003 and the 2005 versions ) and this is a MS press book
( i was also surprised i must admit but it is verry clear in it , and after
reading the explanation i am on there side with my coding style ) .

i am curious why you think it is not good coding practice
 
great thanks
m.posseth said:
"" and string.empty are perfectly equivalent

prove ??


dim x as string =""
dim y as string = string.empty

string.ReferenceEquals(x,y)

this will display true


regards

Michel Posseth [MCP]


academic said:
Are these equivalent

I mean, does x end up the same?

Thanks
Click to expand...
Click to expand...
 
Unless you use a Nothing-String to denote some "meaning" other than Empty,
there is no reason to NOT initialize it to Empty. If you really WANT
*Nothing* for some reason, then that's a different story. But, if you are
just relying on VB's comparison operators and intrinsic functions
(Left,Right,Len, etc) to keep you safe and interpret that Nothing-String as
Empty, you are for sure treading on shaky ground... and it is for sure a BAD
coding practice.

Laziness... not initializing a string and relying on VB's hand-holding is
the same as using Evil-Type-Coercion that we've all gotten past years ago.
Suppose after you leave your company a developer comes along and wants to
add a feature that uses one of the classes that you've written....
If HerfriedWagnerAwesomeControl.Title.Length < 10 Then....
doh! EXCEPTION!
Sadly, this error might not manifest itself until N point in the future when
the app is in Production.
 
academic said:
Why isn't it a good practice?
Click to expand...

I believe it strongly depends on the situation. IMO it's not a good idea to
propose "initialize strings with an empty string" as a general rule.
However, it still may make sense in some cases.
 
The performance differences aren't really noticeable but there IS a
difference!

In the IL:
("") compiles to ldstr "" --- Which means, LoadString, Look it up ("it"
being the char array) in the string table, create a new reference to the
existing string.
(String.Empty) compiles to ldsfld String::Empty --- Which means, LoadField,
push an already existing reference.

Look at it this way:
At its core, S = "" is the same thing as S = New String(New Char() {})
While S = String.Empty is just quite literally S = String.Empty.

If you have "" executed 50 times in your running code, you have created (and
instantly discarded) 50 object references. Sure, all the objects point to
the same string in the string table but still!

2) Lastly, "" forces a scan of the string table (obviously) while
String.Empty does not.
 
Back
Top