Strings.. Objects or not???

[Rigga]

Hi all,

I am wondering why string's are not true objects?.... Let me explain...

If i write the code

Dim x1 as String = "veg"
Dim x2 as String = "veg"

If x1 = x2 then
' i expect this code to be executed
End If

If x1 is x2 then
' i do not expect this code to be executed
End If

However the second lot of code is executed!

Is this correct behavior??? if so is it true then that strings are not true
objects?

Any thoughts would be appreciated!

Rigga.

[Michael G W]

This thread seems to have gone off on tangents everythere.

The original question was if strings are objects. They are, in fact everything is. However some objects do behave differently, like people responding to discussions in news groups.

what does x1 = x2 mean? You need to (thourougly) read the language specs.

is it x1.ReferenceEqu als(x2)

or is it x1.Compare(x2) = 0

also, if its the jit compiler, it does happen at runtime (at least once).

All strings have an internal pointer to their own string. even if those strings happen to contain the same group and length of characters.
"Rigga" wrote:

Thanks all for your replies but I'm still confused.

So coding "veg" anywhere will only ever create one object?

and assigning that object to the reference variable as

x1 as string = "veg"

points to the same object as

x2 as string = "veg"

"veg" being the object?

actually, it has always been kind of strange hat you do not have to code

x1 as New String to instantiate the object.

So we are saying that string does not behave in the same way as other
objects?

Anyway, now that I know this I'll have to code around it.. thanks all..

Rigga.

"Rigga" <s@v.c> wrote in message
news:40******** *************@p tn-nntp-reader04.plus.n et...

Hi all,

I am wondering why string's are not true objects?.... Let me explain...

If i write the code

Dim x1 as String = "veg"
Dim x2 as String = "veg"

If x1 = x2 then
' i expect this code to be executed
End If

If x1 is x2 then
' i do not expect this code to be executed
End If

However the second lot of code is executed!

Is this correct behavior??? if so is it true then that strings are not

true

objects?

Any thoughts would be appreciated!

Rigga.

[Jon Skeet [C# MVP]]

<"=?Utf-8?B?TWljaGFlbCB HIFc=?=" <Michael G
W@discussions.m icrosoft.com>> wrote:

This thread seems to have gone off on tangents everythere.

The original question was if strings are objects. They are, in fact
everything is. However some objects do behave differently, like
people responding to discussions in news groups.

what does x1 = x2 mean? You need to (thourougly) read the language
specs.
Not sure about VB, but in C# you don't need to read the language specs
particularly thoroughly - you just need to see that String overloads
the equality operator, just as other classes can.
is it x1.ReferenceEqu als(x2)

or is it x1.Compare(x2) = 0

also, if its the jit compiler, it does happen at runtime (at least
once).
If *what's* the JIT compiler?
All strings have an internal pointer to their own string. even if
those strings happen to contain the same group and length of
characters.

Could you explain that, please? Strings contain their data directly -
there's no extra level of indirection.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Abubakar]

I know you are talking about VB.net but check this, in VC++ there is a compiler option called /Gf or /GF, that creates single copy of identical strings in the program image and memory during execution, resulting in smaller programs, an optimization called *string pooling*.
I think this optimization is already built in to VB.net compiler and hence you get this kind of behavior in VB apps.
Any body plz correct me if I'm wrong.

Hope that helps.

Abubakar.
http://joehacker.blogspot.com

"Rigga" wrote:

Hi all,

I am wondering why string's are not true objects?.... Let me explain...

If i write the code

Dim x1 as String = "veg"
Dim x2 as String = "veg"

If x1 = x2 then
' i expect this code to be executed
End If

If x1 is x2 then
' i do not expect this code to be executed
End If

However the second lot of code is executed!

Is this correct behavior??? if so is it true then that strings are not true
objects?

Any thoughts would be appreciated!

Rigga.

[Bob Grommes]

I think you are talking about string interning, or the string interning
pool, or just plain string pool. This is automatically the behavior of C#
as well as VB.NET -- for constants. You can also take advantage of it for
any string you manipulate, by using String.Intern() . The disadvantage is
that it can slow string assignments down (due to the overhead of searching
the string pool to see if the string needs to be added or if an existing
reference can be returned). However, in many instances this
often-overlooked technique can save tremendous amounts of memory. Many
tables of string values have a lot of repetition.

--Bob

"Abubakar" <Ab******@discu ssions.microsof t.com> wrote in message
news:4C******** *************** ***********@mic rosoft.com...

I know you are talking about VB.net but check this, in VC++ there is a compiler option called /Gf or /GF, that creates single copy of identical
strings in the program image and memory during execution, resulting in
smaller programs, an optimization called *string pooling*. I think this optimization is already built in to VB.net compiler and hence you get this kind of behavior in VB apps. Any body plz correct me if I'm wrong.

Hope that helps.

Abubakar.
http://joehacker.blogspot.com

"Rigga" wrote:

Hi all,

I am wondering why string's are not true objects?.... Let me explain...

If i write the code

Dim x1 as String = "veg"
Dim x2 as String = "veg"

If x1 = x2 then
' i expect this code to be executed
End If

If x1 is x2 then
' i do not expect this code to be executed
End If

However the second lot of code is executed!

Is this correct behavior??? if so is it true then that strings are not true objects?

Any thoughts would be appreciated!

Rigga.

[David]

On 2004-07-11, Lucky Carl <ca********@yah oo.no.spam> wrote:

Ok, so if

string y1 = "abcdefghijklmn opqrstuvwxy"
string y2 = "abcdefghijklmn opqrstuvwxyz"

That means that y1 is created, then a search algorithm does a string search
all the way to 'y' and then says -- opps, gotta create a new object.

Man. Talk about /overhead/
Sure, but it's compile-time overhead. Which isn't really a big deal.

[David]

On 2004-07-09, Lance Wynn <la********@N.O .S.P.A.M.hotmai l.com> wrote:

I believe the String is a true object, but it Overloads the '=' Operator.
so when you write the code x1=x2 the and x1 and x2 are both strings, it will
actually compile the same as x1 is x2.

It really won't.

Dim s as String = "123"
Dim s2 as String = "1234"
s = s & "4"

If s is s2 Then
Console.WriteLi ne("is")
End If

If s = s2 Then
Console.WriteLi ne("=")
End If

[Chris Mullins]

"David" <df*****@woofix .local.dom> wrote

[Strings]

Dim s as String = "123"
Dim s2 as String = "1234"
s = s & "4"

If s is s2 Then
Console.WriteLi ne("is")
End If

If s = s2 Then
Console.WriteLi ne("=")
End If

Strings in .NET are weird. Even this code doesn't do what you probably think
it does.

First off, string are immutable - once created, they're not changed. Only
new strings are created. Interning of strings confuses the issues quite a
bit.

A fairly good overview seems to be at:
http://www.sliver.com/dotnet/emails/default.aspx?id=6

Richter, in his .NET book, has a pretty good explination of strings as well.
He also gets into the encoding (UTF8/16) issues surrounding strings
including the StringInfo class and all sorts of other goodies.

--
Chris Mullins

[Peter Bromley]

>>I believe the String is a true object, but it Overloads the '=' Operator.

so when you write the code x1=x2 the and x1 and x2 are both strings, it will
actually compile the same as x1 is x2.

It really won't.

Dim s as String = "123"
Dim s2 as String = "1234"
s = s & "4"

If s is s2 Then
Console.WriteLi ne("is")
End If

If s = s2 Then
Console.WriteLi ne("=")
End If

So the lesson here is don't ever use the '=' Operator with strings.

You must use the Equals method for comparison.

Personally speaking, I would have thought it made more sense that the
string class overrode the '=' operator so that it behaved as the Equals
method (thus making the class behave more like a value class) but there
must have been good reasons to do things the way they did....

--
If you wish to reply to me directly, my addres is spam proofed as:

pbromley at adi dot co dot nz

Or if you prefer - no****@nowhere. com :-)

[David]

On 2004-08-03, Peter Bromley <no****@nowhere .com> wrote:

I believe the String is a true object, but it Overloads the '=' Operator.
so when you write the code x1=x2 the and x1 and x2 are both strings, it will
actually compile the same as x1 is x2.

It really won't.

Dim s as String = "123"
Dim s2 as String = "1234"
s = s & "4"

If s is s2 Then
Console.WriteLi ne("is")
End If

If s = s2 Then
Console.WriteLi ne("=")
End If

So the lesson here is don't ever use the '=' Operator with strings.

You must use the Equals method for comparison.

Well, that's not the lesson I'd take. I pretty much use '=' exclusively,
which IMHO does exactly what one would presume it does. In general,
you're usually interested in equality, not identity, and I find that
this is especially true with strings.
Personally speaking, I would have thought it made more sense that the
string class overrode the '=' operator so that it behaved as the Equals
method (thus making the class behave more like a value class) but there
must have been good reasons to do things the way they did....

It does behave as the Equals method. In the above example,

s.Equals(s2)
Object.Equals(s , s2)
s = s2

are all true. Only 's is s2' is false.

[Peter Bromley]

>>

So the lesson here is don't ever use the '=' Operator with strings.

You must use the Equals method for comparison.

Well, that's not the lesson I'd take. I pretty much use '=' exclusively,
which IMHO does exactly what one would presume it does. In general,
you're usually interested in equality, not identity, and I find that
this is especially true with strings.

Well, it's the lesson I painfully learned some months ago :-)

Personally speaking, I would have thought it made more sense that the
string class overrode the '=' operator so that it behaved as the Equals
method (thus making the class behave more like a value class) but there
must have been good reasons to do things the way they did....

It does behave as the Equals method. In the above example,

s.Equals(s2)
Object.Equals(s , s2)
s = s2

are all true. Only 's is s2' is false.

Perhaps there is some difference between VB and C++ but I was
conclusively bitten by my assumption that == and .Equals did the same
thing for Strings.

If you look at the il for the following (C++) code
System::String* s = S"123";
System::String* s2 = S"1234";
s = System::String: :Concat(s, S"4");
bool equal = s == s2;
equal = s->Equals(s2);

The == test compiles to "ceq" on the pointers s1 and s2 and not to a
call to op_Equality as documented in MSDN. Perhaps this is a bug....

I'm curious, what does your VB code compile to for the s = s2 example?

--
If you wish to reply to me directly, my addres is spam proofed as:

pbromley at adi dot co dot nz

Or if you prefer - no****@nowhere. com :-)