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

[academic]

Sounds like the last word to me


Thanks

 

[CMM]

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.

What is the benefit of an uninitialized string? Why is it not a "good idea?"
I mean...
Questions:
1) Are there situations where <Nothing> actually *means* something in your
code and your algorithms other than <Empty>?
2) Or are you just relying on VB's intrinsic functions (Len, Left, Mid, etc)
and "coercion" to safely deal with the string? If so, how do you justify
that?... isn't that the same as using Option-"Loose" "Evil-Type-Coercion?"
3) Is it for performance or memory reasons?

 

[CMM]

Sounds like the last word to me

To clarify... because your original post brought up slightly different
questions:

1) Nothing = Nothing. You're right in assuming that nothing is allocated. A
string initializes to Nothing by default. This leads to bugs... if not for
you then for someone down the road who might have to maintain your code!
While VB's type coercion often hides this from you... for instance trying
s.Length() on a Nothing string will result in an exception. VB won't help
you there.

2) "" = New String(New Char() {})

3) String.Empty = .... um, well, it equals exactly "" ;-)

Obviously, Dim s As String = String.Empty is by far the most efficient and
safest coding practice. I recommend it.

--
-C. Moya
www.cmoya.com

Sounds like the last word to me


Thanks

 

[Herfried K. Wagner [MVP]]

What is the benefit of an uninitialized string? Why is it not a "good
idea?" I mean...
Questions:
1) Are there situations where <Nothing> actually *means* something in
your code and your algorithms other than <Empty>?

Yes! The whole discussion is similar to the 'NULL' vs. zero-length string
or 'NULL' vs. 0 discussion for databases. A zero-length string is different
from a 'Nothing' reference. Inside the .NET Framework's class library they
are not treated as equal.

2) Or are you just relying on VB's intrinsic functions (Len, Left, Mid,
etc) and "coercion" to safely deal with the string?

VB's functions mostly treat "" and 'Nothing' string references as equal.
This means that 'Len', for example, returns 0 for both a 'Nothing' reference
and a zero-length string. In case of a method returning either a 'Nothing'
reference or a string of arbitrary length I'd choose 'If Len(s) > 0 Then'
over 'If s IsNot Nothing AndAlso s.Length > 0 Then' to check if a string
object with length greater than 0 has been returned.

3) Is it for performance or memory reasons?

Performance and memory reasons are not important for me in most cases. I
prefer to write semantically clear code instead of performing
micro-optimizations.

 

[CMM]

Inside the .NET Framework's class library they are not treated as equal.

So why do *you* treat them as if they were?

I mean in *your* code and in your *your algorithms* do you explicitely use
Nothing to accomplish something or do you just let VB's intrinsic operators
or functions interpret it as Empty? In other words, is Nothing treated as
Empty everywhere in your code? To me, that's the same exact thing as writing
stuff like S = 5 where S is a string... when Option Explicit is Off. That's
not "good practice."

You really have to justify why you say "...it's not a good idea to
'initialize strings with an empty string' as a general rule." Why isn't it a
good idea? I mean, 99% of the time, I expect my strings to be Empty not
Nothing. Why not declare them as Empty rather than have VB *coerce* the
value??? That's what I'm trying to understand. I'm not saying you're
wrong... I'm just saying prima facie it doesn't seem to make sense.

 

[Armin Zingler]

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

I've never done it.


Armin

 

[Armin Zingler]

Why isn't it a good practice?

If it has to be an empty string always, use a constant.


Armin

 

[Cor Ligthert [MVP]]

Herfried,

I did not read the whole message just curious where CMM and you where
disussing about.

However I would never compare a database with computer memory.

In a database means a Null field, really nothing which means than as well no
disk space.

In memory that space will be used for other data in another situation of the
method, so there will not be any advantage using it or not. (The memory is
not perstistent).

Just my thought,

Cor

 

[m.posseth]

well i am confused now


Francesco and Giuseppe are verry clear in there book, that both are even
good

"" and string.empty

however from a developers perspective i would use "" as it is faster to
write as string.empty
untill i heard from CMM that the IL produces different code for
string.empty or ""

strange .....

Michel

 

[Cor Ligthert [MVP]]

Academic,

A "" pases a string with one charachter ""

A Nothing passes an object with no reference.

You cam try this
\\\
Dim myfirstobject As Object = Nothing
Dim mysecondobject As String
If myfirstobject Is mysecondobject Then
MessageBox.Show("we both are Nothing")
End If
If myfirstobject IsNot "" Then
MessageBox.Show("we are different")
End If
If myfirstobject IsNot String.Empty Then
MessageBox.Show("we are different")
End If
///

I hope this gives some idea's

Cor

 

[Cor Ligthert [MVP]]

Carlos

1) Nothing = Nothing. You're right in assuming that nothing is allocated.
A string initializes to Nothing by default. This leads to bugs...

A bug is not a hang from the program, a bug is that the result is something
else than there should be.

Initializing to zero can be in some situations be forgiving full. However I
assume that they would be happier on wallstreet with your program if it
would hang, than that on all the invoices would come spaces as price.

Which is as well not prevented with setting it to Nothing, however has still
more a change that the program will hang than that you intialize it.

Just my thought

Cor

 

[CMM]

While the IL does produce different code, I don't think it very much matters
in terms of performance in most situations. If you think "" is easier to
read, and easier for you to type, then you should use it. Personally, I'm a
quick typer and I actually like String.Empty aesthetically versus "" (which
I find to be an eyesore).... But that's a purely subjective thing.

 

[Armin Zingler]

well i am confused now


Francesco and Giuseppe are verry clear in there book, that both are
even good

"" and string.empty

however from a developers perspective i would use "" as it is
faster to write as string.empty
untill i heard from CMM that the IL produces different code for
string.empty or ""

strange .....

I was not referring to "" or string.empty. I wanted to say that it does not
make sense to initalize a string variable with "" (or string.empty) always,
because if it would be a zero length string always, you should better use a
constant instead of a variable.


Armin

 

[Herfried K. Wagner [MVP]]

So why do *you* treat them as if they were?

No, not in general. Only where the difference is irrelevant. I gave you
the sample when I use the 'Len' function instead of 'String.Length'. That's
just one sample. If I want to get the rightmost three characters of a
string, I use 'Right' instead of 'String.Substring', because it won't throw
an exception if the string reference passed to it is pointing to 'Nothing'.
Note that these are not samples of treating 'Nothing' as equal to "".

You really have to justify why you say "...it's not a good idea to
'initialize strings with an empty string' as a general rule." Why isn't it
a good idea? I mean, 99% of the time, I expect my strings to be Empty not
Nothing.

\\\
Dim s As String = String.Empty
....
s = DoSomething()
///

.... initializing 's' is completely useless in the sample above and adds
additional initialization overhead. That's why I wrote that it doesn't make
sense to initialize /every/ string variable with 'String.Empty' or ""
instead of letting VB.NET initialize it with a 'Nothing' reference.

Why not declare them as Empty rather than have VB *coerce* the value???

Initializing variables with a certain value doesn't make sense other code
prior to the first read-access assigns a value to the variable.

 

[Herfried K. Wagner [MVP]]

I did not read the whole message just curious where CMM and you where
disussing about.

However I would never compare a database with computer memory.

In a database means a Null field, really nothing which means than as well
no disk space.

'NULL' in a database means "unknown value". This behavior can be replicated
inside VB.NET in different ways ('Nothing' references, 'Nullable(Of
String)').

 

[Herfried K. Wagner [MVP]]

While the IL does produce different code, I don't think it very much
matters in terms of performance in most situations.

I'm curious why the compiler doesn't emit the same IL instruction for "" it
does for 'String.Empty'. Maybe this will change in a future version as part
of a compiler optimization.

 

[Herfried K. Wagner [MVP]]

A "" pases a string with one charachter ""

I think you wanted to type "with zero characters" as strings in VB are not
null-terminated.

 

[Cor Ligthert [MVP]]

Herfried,

'NULL' in a database means "unknown value". This behavior can be
replicated inside VB.NET in different ways ('Nothing' references,
'Nullable(Of String)').

It means no value, although what constraints it has to fullfil if there is a
value is known.

Cor

 

[Cor Ligthert [MVP]]

Herfried,

A "" pases a string with one charachter ""

I think you wanted to type "with zero characters" as strings in VB are not
null-terminated.

Exact I typed it, saw what bs I wrote, wanted to correct it, could not
direct get the right term and forgot it

Thanks,

Cor

 

[academic]

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.

What does "Look it up" mean.

Does it look up every time I assign a value to a string variable to see if
that value is already in a table?