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

[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

[AMercer]

> 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.

[m.posseth]

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]

" academic" <ac******@a-znet.com> schreef in bericht
news:eT***************@TK2MSFTNGP15.phx.gbl...

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

[Mattias Sjögren]

>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 "".
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?

Yes.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Mattias Sjögren]

it is considered good coding practice to initialize string values with a
empty string value

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

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[academic]

"m.posseth" <po*****@planet.nl> wrote in message
news:uI**************@TK2MSFTNGP15.phx.gbl...

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

Are these equivalent

I mean, does x end up the same?

Thanks

[academic]

"AMercer" <AM*****@discussions.microsoft.com> wrote in message
news:5C**********************************@microsof t.com...

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.

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

Thanks

[academic]

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:el**************@tk2msftngp13.phx.gbl...

it is considered good coding practice to initialize string values with a
empty string value

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.

I wonder why not - is there some reason to use Nothing and then check?

[m.posseth]

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.
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" <ma********************@mvps.org> schreef in bericht
news:el**************@tk2msftngp13.phx.gbl...

it is considered good coding practice to initialize string values with a
empty string value

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

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Herfried K. Wagner [MVP]]

" academic" <ac******@a-znet.com> schrieb:

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

Are these equivalent

I mean, does x end up the same?

Yes, it ends up in an empty string (string of length zero) too.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

"m.posseth" <po*****@planet.nl> schrieb:

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.

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 )

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[academic]

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:eR**************@tk2msftngp13.phx.gbl...

But with "" it is - correct?
Yes. But that shouldn't stop you from using it if appropriate.

I can't think of a situation where it is appropriate ( which is not to imply
that I think there isn't any)

The system seems to handle a null the same as "".
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.

That's explains a lot

What about passing to a Windows API?

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

Yes.

I believe passing Nothing would cause a zero to be put on the stack.

What does pass "" do?

Thanks

[m.posseth]

"" 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]
" academic" <ac******@a-znet.com> schreef in bericht
news:u7*************@TK2MSFTNGP10.phx.gbl...

"m.posseth" <po*****@planet.nl> wrote in message
news:uI**************@TK2MSFTNGP15.phx.gbl...

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

Are these equivalent

I mean, does x end up the same?

Thanks

[m.posseth]

> Mhm... That's why I use 'Right', 'Left', 'Len', etc. if I do not want

exceptions to be thrown on string variables referencing 'Nothing'.
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.
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
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schreef in bericht
news:%2****************@TK2MSFTNGP12.phx.gbl... "m.posseth" <po*****@planet.nl> schrieb:

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.

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 )

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[academic]

Why isn't it a good practice?

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

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[academic]

great thanks
"m.posseth" <po*****@planet.nl> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

"" 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" <ac******@a-znet.com> schreef in bericht
news:u7*************@TK2MSFTNGP10.phx.gbl...

"m.posseth" <po*****@planet.nl> wrote in message
news:uI**************@TK2MSFTNGP15.phx.gbl...

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

Are these equivalent

I mean, does x end up the same?

Thanks

[academic]

Thanks
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:em**************@TK2MSFTNGP14.phx.gbl...

" academic" <ac******@a-znet.com> schrieb:

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

Are these equivalent

I mean, does x end up the same?

Yes, it ends up in an empty string (string of length zero) too.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[CMM]

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.
--
-C. Moya
www.cmoya.com
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

"m.posseth" <po*****@planet.nl> schrieb:

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.

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 )

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

" academic" <ac******@a-znet.com> schrieb:

Why isn't it a good practice?

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

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[CMM]

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.
--
-C. Moya
www.cmoya.com

[academic]

Sounds like the last word to me
Thanks

"CMM" <cm*@nospam.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...

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.
--
-C. Moya
www.cmoya.com

[CMM]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ua**************@TK2MSFTNGP15.phx.gbl...

" academic" <ac******@a-znet.com> schrieb:
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?

--
-C. Moya
www.cmoya.com

[CMM]

" academic" <ac******@a-znet.com> wrote in message ...

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
" academic" <ac******@a-znet.com> wrote in message
news:uf**************@TK2MSFTNGP15.phx.gbl... Sounds like the last word to me
Thanks

"CMM" <cm*@nospam.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...

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.
--
-C. Moya
www.cmoya.com

[Herfried K. Wagner [MVP]]

"CMM" <cm*@nospam.com> schrieb:

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>?

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[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.
--
-C. Moya
www.cmoya.com

[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

[Armin Zingler]

"m.posseth" <po*****@planet.nl> schrieb

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]

" academic" <ac******@a-znet.com> schrieb

Why isn't it a good practice?

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

[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

"Armin Zingler" <az*******@freenet.de> schreef in bericht
news:Oc**************@TK2MSFTNGP14.phx.gbl...

" academic" <ac******@a-znet.com> schrieb

Why isn't it a good practice?

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

[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.

--
-C. Moya
www.cmoya.com

[Armin Zingler]

"m.posseth" <po*****@planet.nl> schrieb

" academic" <ac******@a-znet.com> schrieb

Why isn't it a good practice?

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

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]]

"CMM" <cm*@nospam.com> schrieb:

Inside the .NET Framework's class library they are not treated as equal.
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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:

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)').

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

"CMM" <cm*@nospam.com> schrieb:

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:

A "" pases a string with one charachter ""

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

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[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]

"CMM" <cm*@nospam.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...

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?

[CMM]

> 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 ""

Dim s As String = DoSomething()
is the answer.

Seems to me that you're still holding on to the VB.Classic notion of
"Declaring" variables at the top of a method rather Instantiating them when
you need them in a block so that they're destroyed when the block ends.

If Condition Then
Dim s As String = DoSomething()
'do work
End If

The benefits of this coding style are many and hard to explain unless you
work in a team or are otherwise mindful of future developers maintaining
your software. Curious, do you work in a team or alone?

[CMM]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:em**************@TK2MSFTNGP09.phx.gbl...

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.

They could do it as an optional "optimization" of sorts where the VB
compiler sees "" and replaces it with String.Empty (behind-the-scenes)
before compiling. But the reason of "why" is very clear. One is a literal
that has to be boxed and turned into an object in order to be used (because
that's the way stuff works) and the other is already an object.

--
-C. Moya
www.cmoya.com

[Mattias Sjögren]

One is a literal
that has to be boxed and turned into an object in order to be used (because
that's the way stuff works) and the other is already an object.

There's no boxing going on here, string is a reference type.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Mattias Sjögren]

>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 :-)
Then I guess I'll have to disagree with them, it wouldn't be the first
time.

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

I won't trade correctness for simplicity. Assigning "" to strings by
default, just to avoid NullReferenceExceptions, feels like a hack that
will just hide the actual problem. Exceptions can be good things if
they help you find errors during development, suppressing them is
taking the easy way out.

Do they also recommend catch-all exception handling (or On Error
Resume Next style programming)?
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[CMM]

"Mattias Sjögren" <ma********************@mvps.org> wrote in message

There's no boxing going on here, string is a reference type.

A boxing is an object. That literal in your code isn't.
From MSDN:
Boxing is the process of converting a literal, like a single space, to the
implied object (in this case, a string object) for that literal.

--
-C. Moya
www.cmoya.com

[CMM]

> I won't trade correctness for simplicity. Assigning "" to strings by

default, just to avoid NullReferenceExceptions, feels like a hack that
will just hide the actual problem.
Using VB's type emptystring type coercion is more of a hack. The actual
problem is that a string should mean something unless you really need it not
to. You don't have to initialize it to "" or String.Empty. You can
initialize it when you NEED it as so: Dim s As String = SomeMethod(). What's
wrong with that?
.... AND even better.... declare it inside blocks (If, Loops, etc) so it goes
out of scope at the end of the block. Man, this is just programming 101.

If VB developer's are still putting dozens of Dim's at the top of their
methods, boy, that doesn't bode well for the future of this platform. Dim in
VB.NET is not the same ol' VB.Classic Dim. They're missing out on the whole
point.
Exceptions can be good things if
they help you find errors during development, suppressing them is
taking the easy way out.

Initializing string is not suppressing an exception. Using Len(str) insetad
of str.Length *IS* suppressing it.

Fact is, pretty much the entire programming world has settled on the notion
that this is good practice. In C++ it's practically a law. In C# it's just a
darn good practice. It's only in VB where developers feel free to be
super-lazy and write horribly and hard to maintain code if they so wished
where this seems to be tolerated.

--
-C. Moya
www.cmoya.com

[Cor Ligthert [MVP]]

Carlos,

Seems to me that you're still holding on to the VB.Classic notion of
"Declaring" variables at the top of a method rather Instantiating them
when you need them in a block so that they're destroyed when the block
ends.

This is not from the VB notation, it comes from the old days and is based on
the hardware type programming.

If you have to debug using the little bulps on a computer, than you are glad
that the data is seperated from the instructions and that you not have to
calculate a next program word what is behind x positions of data (or a
previous before).

I agree completely with you, that this is now without any sense and prefer
very much the way you describe.

I hope that it is clear what I write?

Cor

[Mattias Sjögren]

The performance differences aren't really noticeable but there IS a
difference!
Can you post some numbers?

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!

You make it sound like an object reference is an object in itself that
requires dynamic memory allocation. But they are just "pointers"
stored in preallocated space in registers, on the stack or in a field.
No dynamic allocation needed, so I don't see your point.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Mattias Sjögren]

A boxing is an object. That literal in your code isn't.
From MSDN:
Boxing is the process of converting a literal, like a single space, to the
implied object (in this case, a string object) for that literal.

That quote seems to be from an article by Paul Sheriff, and he seems
to have come up with his own definition of the term boxing. That's
unfortunate, because if we don't have a common terminology it gets
pretty hard and confusing to discuss things like this.

The .NET framework docs have a different definition that I follow:

"The conversion of a value type instance to an object, which implies
that the instance will carry full type information at run time and
will be allocated on the heap."

http://msdn2.microsoft.com/en-us/library/b85sw2k8.aspx

See, nothing about literals and it specifically says value types.
Frankly I don't understand where Mr Sheriff his version from.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[CMM]

I guess you'd have to understand what boxing means... semantically I guess.

Without knowledge of what a "value type" really is (a set of bytes--
otherwise known as intrinsic or primitive types) and how a string (an array
of bytes) is stored in a table and referenced by an "Object", then you would
be confused.

Again, that literal "" in your code does not refer to an object. It has to
be converted to (boxed? use whatever term you want to use) into an object.

--
-C. Moya
www.cmoya.com
"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:uU**************@TK2MSFTNGP12.phx.gbl...

A boxing is an object. That literal in your code isn't.
From MSDN:
Boxing is the process of converting a literal, like a single space, to the
implied object (in this case, a string object) for that literal.

That quote seems to be from an article by Paul Sheriff, and he seems
to have come up with his own definition of the term boxing. That's
unfortunate, because if we don't have a common terminology it gets
pretty hard and confusing to discuss things like this.

The .NET framework docs have a different definition that I follow:

"The conversion of a value type instance to an object, which implies
that the instance will carry full type information at run time and
will be allocated on the heap."

http://msdn2.microsoft.com/en-us/library/b85sw2k8.aspx

See, nothing about literals and it specifically says value types.
Frankly I don't understand where Mr Sheriff his version from.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.