Strings + vs &

[Boni]

Dear all,
Is there any perfomance difference in string concatination using "+" vs "&"?
I think, that compiler produces the same code for both. Am I right?
Thank you,
Boni

 

[shiv_koirala]

Both have same speed if it is string concatenation.+ operator is late
bound and must perform type checking and conversions.

Regards ,
C#, VB.NET , SQL SERVER , UML , DESIGN Patterns Interview question book
http://www.geocities.com/dotnetinterviews/

 

[Guest]

Even though performance is likely the same, I recommend using & since there
are cases where it will compile but behave differently from what you expect
if you use +.
(I haven't got an example handy, but they exist...)
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant J#: VB.NET to J# Converter
Clear VB: Cleans up outdated VB.NET code

 

[Cor Ligthert [MVP]]

Boni,

There are situations where the + starts counting. So try to use forever the
& for concatination in VB.Net

I thought that it was that with option strict of this sentence is valid

"111" + 1 it gives you "112"
while
"111" & 1 gives you than 1111

I hope this helps,

Cor

 

[Dragon]

Hi Boni,

No, they are not the same.
"+" operator is for string concatenation if *both* of the arguments are
Strings. If not, it performs addition and returns Double.
"&" operator is for string concatenation only. Both arguments are
converted to String.

Quick example:

~
REM Compile with Option Strict Off
MessageBox.Show("5" + 6)
MessageBox.Show("5" & 6)
~

I hope this helps,
Roman

 

[m.posseth]

well in addition to the other comments
you could also use dim test as string= string.concat("hello"," how ",
"are ", "you ", "today")

 

[david]

Dear all,
Is there any perfomance difference in string concatination using "+" vs "&"?
I think, that compiler produces the same code for both. Am I right?

With Option Strict On, they behave identically. AFAIK, there's no
ambiguity issues or performance issues, apart from the obvious point
that '+' also works with numeric types.

BTW, I agree with the other posters here that '&' is clearer and should
be preferred.

 

[Herfried K. Wagner [MVP]]

With Option Strict On, they behave identically. AFAIK, there's no
ambiguity issues or performance issues, apart from the obvious point
that '+' also works with numeric types.

BTW, I agree with the other posters here that '&' is clearer and should
be preferred.

'&' has the additional advantage that it automatically converts the operands
to 'String'.

 

[Cor Ligthert [MVP]]

'&' has the additional advantage that it automatically converts the
operands to 'String'.

Is this not something as the same advantage as that when you are laying on
the ground you can not fall?



Cor

 

[david]

'&' has the additional advantage that it automatically converts the
operands to 'String'.

Does it? ... Yuck, it does. I didn't know that. That's just evil,
and smells of ETC. So that makes me wonder if '+' is actually the
better solution here.

Dim s as String = "Hello"
Dim i As Integer = 5

Dim s3 As String

s3 = s & i
s3 = s + i

The second doesn't compile, and IMHO that's the more correct behavior.
So why are we all using '&' again?

 

[Guest]

option strict on and use string.concat

this will never give unexpected behavior

and it will give you the advantage that you already know some syntaxt when
switching to another .Net Language

& performs also a concat so there is no speed gain or benefit
except when you are using non string vars will concat probably be faster as
the conversion is not necessary ( it is already enforced in dev time )

regards

Michel

 

[Herfried K. Wagner [MVP]]

Does it? ... Yuck, it does. I didn't know that. That's just evil,
and smells of ETC. So that makes me wonder if '+' is actually the
better solution here.

Dim s as String = "Hello"
Dim i As Integer = 5

Dim s3 As String

s3 = s & i
s3 = s + i

The second doesn't compile, and IMHO that's the more correct behavior.
So why are we all using '&' again?

I don't see such a big problem here. '&' not only documents that it will
perform a string concatenation, it will also tell the reader that conversion
will be done automatically. It is even allowed to mix '+' and '&' to do
calculations:

\\\
Dim n As Integer = 12
MsgBox("The number is " & n + 1 & ".")
///

Personally I really like this feature .

 

[Herfried K. Wagner [MVP]]

option strict on and use string.concat

this will never give unexpected behavior

.... but it will lead to "unreadable" code.

and it will give you the advantage that you already know some syntaxt when
switching to another .Net Language

Mhm... It's pretty easy to look up the string concatenation operator for
another programming language, isn't it?

& performs also a concat so there is no speed gain or benefit
except when you are using non string vars will concat probably be faster
as
the conversion is not necessary ( it is already enforced in dev time )

I recommend not to use 'String.Concat' when concatenating string literals.
Consider the following code:

\\\
MsgBox(String.Concat("Bla", "Foo"))
MsgBox("Bla" & "Foo")
///

Corresponding VB 7.1/.NET 1.1 IL:

\\\
IL_0001: ldstr "Bla"
IL_0006: ldstr "Foo"
IL_000b: call string [mscorlib]System.String::Concat(string,
string)
IL_0010: ldc.i4.0
IL_0011: ldnull
IL_0012: call valuetype
[Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxResult
[Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object,


valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxStyle,


object)
IL_0017: pop
IL_0018: ldstr "BlaFoo"
IL_001d: ldc.i4.0
IL_001e: ldnull
IL_001f: call valuetype
[Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxResult
[Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object,
///

As you can see, the compiler will perform the string concatenation done
using the '&' operator at compile-time, if possible, whereas this isn't the
case for 'String.Concat'.

 

[m.posseth]

well that is strange

As i recently read an article where was stated that & and string.concat
are the same with a slight twist & would first perform a string conversion
while this by concat must be enforced
in your example it would mean that the & operator would actually be faster

... but it will lead to "unreadable" code.

well it is just what you prefer ,,,, unexpected behavior or strictness in
your code i would go for the last one


however if it is really so that the & operator produces faster code
execution i would go in some situations for this options

i will investigate this ;-)

option strict on and use string.concat

this will never give unexpected behavior

... but it will lead to "unreadable" code.

and it will give you the advantage that you already know some syntaxt
when
switching to another .Net Language

Mhm... It's pretty easy to look up the string concatenation operator for
another programming language, isn't it?

& performs also a concat so there is no speed gain or benefit
except when you are using non string vars will concat probably be faster
as
the conversion is not necessary ( it is already enforced in dev time )

I recommend not to use 'String.Concat' when concatenating string literals.
Consider the following code:

\\\
MsgBox(String.Concat("Bla", "Foo"))
MsgBox("Bla" & "Foo")
///

Corresponding VB 7.1/.NET 1.1 IL:

\\\
IL_0001: ldstr "Bla"
IL_0006: ldstr "Foo"
IL_000b: call string [mscorlib]System.String::Concat(string,
string)
IL_0010: ldc.i4.0
IL_0011: ldnull
IL_0012: call valuetype
[Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxResult
[Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object,

valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxStyle,

object)
IL_0017: pop
IL_0018: ldstr "BlaFoo"
IL_001d: ldc.i4.0
IL_001e: ldnull
IL_001f: call valuetype
[Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxResult
[Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object,
///

As you can see, the compiler will perform the string concatenation done
using the '&' operator at compile-time, if possible, whereas this isn't
the case for 'String.Concat'.

 

[david]

I don't see such a big problem here. '&' not only documents that it will
perform a string concatenation, it will also tell the reader that conversion
will be done automatically.

Well, since I've never noticed this in a few years of VB.Net, I don't
think it's a particularly big problem. Still, I'd prefer the type
safety to the convenience.

 

[Cor Ligthert [MVP]]

David,

In my opinion it is not well tho show this as sample in the newsgroup, there
is nothing wrong with it. However, it can be read in another way by persons
who don't understand your intention.

(With this message I told this)



Cor

 

[Herfried K. Wagner [MVP]]

In my opinion it is not well tho show this as sample in the newsgroup,
there is nothing wrong with it. However, it can be read in another way by
persons who don't understand your intention.

It's me who showed the example. And yes, I believe that it's pretty clear
what the sample does.