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.ReferenceEquals(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*********************@ptn-nntp-reader04.plus.net...

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.

[Cor Ligthert]

>

Only when it's a string literal. Strings aren't interned automatically
in other situations. It doesn't affect normal string creation.

Explain?

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no**********@planet.nl> wrote:

Only when it's a string literal. Strings aren't interned automatically
in other situations. It doesn't affect normal string creation.

Explain?

Sure. When you've got two string literals which contain the same
characters, you only end up with one string. If you create two
equivalent strings dynamically, however, you end up with two different
string objects.

For instance, in C#:

string x = "hello";
string y = "hello";

StringBuilder sb = new StringBuilder();
sb.Append(x);
string a = sb.ToString();

sb = new StringBuilder();
sb.Append(x);
string b = sb.ToString();

x and y are references to the same string. a and b are references to
different strings - so there are 3 strings in total in the above.

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

[Jon Skeet [C# MVP]]

<"=?Utf-8?B?TWljaGFlbCBHIFc=?=" <Michael G
[e-mail]>> 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.ReferenceEquals(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.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon,

For instance, in C#:

string x = "hello";
string y = "hello";

StringBuilder sb = new StringBuilder();
sb.Append(x);
string a = sb.ToString();

sb = new StringBuilder();
sb.Append(x);
string b = sb.ToString();

Are you sure of this, I did not check this however what you write in my
translation is that "string a" and "string b" are not strings however
references to a stringbuilder object, which holds strings, which are not
strings. And in that case there is only one string and two objects which has
maybe a concationation of characters and is not a string in the meaning of
this however a method.

I am not saying you are wrong, as you wrote (and what was committed by me)
is that the String is a kind of strange object.

The String looks for me as a legacy C method which is inherited in dotNet.

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no**********@planet.nl> wrote:

For instance, in C#:

string x = "hello";
string y = "hello";

StringBuilder sb = new StringBuilder();
sb.Append(x);
string a = sb.ToString();

sb = new StringBuilder();
sb.Append(x);
string b = sb.ToString();

Are you sure of this
Absolutely. It's very easy to test:

using System;
using System.Text;

class Test
{
static void Main()
{
string x = "hello";
string y = "hello";

StringBuilder sb = new StringBuilder();
sb.Append(x);
string a = sb.ToString();

sb = new StringBuilder();
sb.Append(x);
string b = sb.ToString();

Console.WriteLine (object.ReferenceEquals(x, y));
Console.WriteLine (object.ReferenceEquals(x, a));
Console.WriteLine (object.ReferenceEquals(x, b));
Console.WriteLine (object.ReferenceEquals(a, b));
}
}
I did not check this however what you write in my
translation is that "string a" and "string b" are not strings however
references to a stringbuilder object, which holds strings, which are not
strings.
No, they're strings (or rather, string references).
StringBuilder.ToString() returns a string. The StringBuilder object
itself can be garbage collected after its use.
And in that case there is only one string and two objects which has
maybe a concationation of characters and is not a string in the meaning of
this however a method.
No, they're both strings. Otherwise they wouldn't be able to be held by
string variables, would they?

Other than the fact that the object x and y refer to are interned and
the objects a and b refer to aren't, there's basically no difference
between them.
I am not saying you are wrong, as you wrote (and what was committed by me)
is that the String is a kind of strange object.
It's not nearly as strange as some people think, to be honest.
The String looks for me as a legacy C method which is inherited in dotNet.

Nonsense - pretty much every development platform ever created has
strings.

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

[Cor Ligthert]

Jon,

No, they're strings (or rather, string references).
StringBuilder.ToString() returns a string. The StringBuilder object
itself can be garbage collected after its use.
Got it and made the sample more easy,

using System;
using System.Text;
class Test
{static void Main()
{string x = "hello";
string y = "hello";
string z = "hellom";
z = z.Substring(0,5);
Console.WriteLine (object.ReferenceEquals(x, y));
Console.WriteLine (object.ReferenceEquals(x, z));}}

Which means for me that only when the String is made as a constant it is
referencing to that constant object which can only be once in memory, and
therefore it has nothing to do with Strings however with constants.

(Correct me in this when I am wrong)
Nonsense - pretty much every development platform ever created has
strings.

That is nonsense itself, not every development platform had strings it is
only something from I think the last 25 years. Before that it was as I
showed you only an memoryaddress with the words and the length of those or
the end point of those.

Cobol by instance did not have it, although a pic X(10) Value "Jon Skeet"
you can call a string.

(I have seen systems with 24bits words. While now it is mostly that a word
is a synonime for a byte with usable 8 bits)

:-)

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no**********@planet.nl> wrote:

No, they're strings (or rather, string references).
StringBuilder.ToString() returns a string. The StringBuilder object
itself can be garbage collected after its use.
Got it and made the sample more easy,

using System;
using System.Text;
class Test
{static void Main()
{string x = "hello";
string y = "hello";
string z = "hellom";
z = z.Substring(0,5);
Console.WriteLine (object.ReferenceEquals(x, y));
Console.WriteLine (object.ReferenceEquals(x, z));}}

Yes, that's a good simplification. (Just using "hellom".Substring(0, 5)
would work too.)
Which means for me that only when the String is made as a constant it is
referencing to that constant object which can only be once in memory, and
therefore it has nothing to do with Strings however with constants.

(Correct me in this when I am wrong)
Well, those string literals *are* still strings - they act just like
other strings apart from this one interning part.

Note also that you can intern other strings, using String.Intern.

Nonsense - pretty much every development platform ever created has
strings.

That is nonsense itself, not every development platform had strings it is
only something from I think the last 25 years. Before that it was as I
showed you only an memoryaddress with the words and the length of those or
the end point of those.

Cobol by instance did not have it, although a pic X(10) Value "Jon Skeet"
you can call a string.

Exactly - even if they didn't *call* them strings, the concept was
still there. I don't see why you're dismissing it as a legacy concept -
what would you replace it with?
(I have seen systems with 24bits words. While now it is mostly that a word
is a synonime for a byte with usable 8 bits)

Um, I don't think so, actually. "Word" can have varying meanings.
What's more confusing is that "byte" doesn't always mean "8 bits" -
maybe that's what you meant?

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

[Cor Ligthert]

Jon,

Exactly - even if they didn't *call* them strings, the concept was
still there. I don't see why you're dismissing it as a legacy concept -
what would you replace it with?
The difference is the mutability. In Cobol it is very easy to rename your
bytearea and use it by instance to set even a bit in a completly different
way. This was done by instance when there was needed memory or simple to do
things what now is done with methods as SubString.

Later there came concepts which where more dedicated to "Variables", you
maybe think different however I hated that because you had completly no
control over the memory anymore (This is not a part of C therefore I did
express write *Methods* of C, pointing on made methods), it was in by
instance in Basic the most terrible for people like me, however with that I
do not prickle you.

:-)

I find the immutability of the string a kind of legacy from that "Variable"
time, however just an idea, which does not botter me at all now we have so
much memory.

(I have seen systems with 24bits words. While now it is mostly that a word is a synonime for a byte with usable 8 bits)

Um, I don't think so, actually. "Word" can have varying meanings.
What's more confusing is that "byte" doesn't always mean "8 bits" -
maybe that's what you meant?

It was in past always confusing when there was talked about words, so at a
certain moment suddenly everybody was talking about Bytes, while in the
beginning there were only 8bits words ment with that.

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no**********@planet.nl> wrote:

Exactly - even if they didn't *call* them strings, the concept was
still there. I don't see why you're dismissing it as a legacy concept -
what would you replace it with?
The difference is the mutability.

In that case, you're definitely not talking about a C/C++ legacy, as
std::strings are mutable, and in C there's nothing to stop you from
changing the memory.
In Cobol it is very easy to rename your
bytearea and use it by instance to set even a bit in a completly different
way. This was done by instance when there was needed memory or simple to do
things what now is done with methods as SubString.

Later there came concepts which where more dedicated to "Variables", you
maybe think different however I hated that because you had completly no
control over the memory anymore (This is not a part of C therefore I did
express write *Methods* of C, pointing on made methods), it was in by
instance in Basic the most terrible for people like me, however with that I
do not prickle you.
Didn't understand any of that, but never mind.
I find the immutability of the string a kind of legacy from that "Variable"
time, however just an idea, which does not botter me at all now we have so
much memory.

It's certainly not a C/C++ legacy. Java has immutable strings, and I
think they're wonderful - I'd rather not worry about other methods
changing the contents of my strings, etc. It also means that the amount
of memory required doesn't change - if you wanted to expand a string,
it could require relocation and copying, etc, which is a general pain.

<snip>

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

[Cor Ligthert]

Jon,

It's certainly not a C/C++ legacy.

That is what I tried to write in the part you did not understand.

And with that denying a previous message of me where I pointed on that while
afterwards I thought doh, wrong.

I think that all is clear now, can it now be EOT?

Cor

[Michael Giagnocavo [MVP]]

Not always. The literals point to an offset in the stringheap. So as long as
the offsets into the string heap are the same, we know the strings are the
same. Not having reviewed the source code for this part of the CLR, I'm not
sure how they handle it, but I'd be highly surprised if they skip this
optimization.

-Michael
MVP
www.atrevido.net

At the lower levels, when a string is matched agaist another two strings
being matched of 99 'z''s one followed by 1 and the other by 2 will take
longer to match than two similar strings both of length 10

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .

Time flies when you don't know what you're doing

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...

Jon,

We know that the immutability of a string takes time, thinking about
this subject we know that it takes maybe even more time than we think to
create a string.

So better?

Cor

[The Grim Reaper]

YES!!! EOT!!! STOP!!
________________________________
Grim

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:OZ**************@TK2MSFTNGP10.phx.gbl...

Jon,

It's certainly not a C/C++ legacy.
That is what I tried to write in the part you did not understand.

And with that denying a previous message of me where I pointed on that

while afterwards I thought doh, wrong.

I think that all is clear now, can it now be EOT?

Cor

[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******@discussions.microsoft.com> wrote in message
news:4C**********************************@microsof t.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********@yahoo.no.spam> wrote:

Ok, so if

string y1 = "abcdefghijklmnopqrstuvwxy"
string y2 = "abcdefghijklmnopqrstuvwxyz"

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.hotmail.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.WriteLine("is")
End If

If s = s2 Then
Console.WriteLine("=")
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.WriteLine("is")
End If

If s = s2 Then
Console.WriteLine("=")
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.WriteLine("is")
End If

If s = s2 Then
Console.WriteLine("=")
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.WriteLine("is")
End If

If s = s2 Then
Console.WriteLine("=")
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 :-)

[Jon Skeet [C# MVP]]

Peter Bromley <no****@nowhere.com> wrote:

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 afraid I don't know whether MC++ is meant to use the overloaded ==
operator in the same way that C# does. (Using == in the C# version of
the above would be fine.)
I'm curious, what does your VB code compile to for the s = s2 example?

It compiles to a call to
Microsoft.VisualBasic.CompilerServices.StringType. Strcmp(s, s2, false).

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

[David]

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

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.

The difference is that the vb '=' and the c++/c# '==' are not the same
operators. in VB, the '=' operator compares strings for equality.
Technically, there are some differences between it and .Equals, but
for the most part they can be treated as if they did the same thing.

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?

As Jon said, it compiles to
Microsoft.VisualBasic.CompilerServices.StringType: :StrCmp(s,s2,false)

The 'Is' operator compiles to a ceq instruction.

[Peter Bromley]

Jon Skeet [C# MVP] wrote:

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 afraid I don't know whether MC++ is meant to use the overloaded ==
operator in the same way that C# does. (Using == in the C# version of
the above would be fine.)

Well, from my reading of MSDN, if a type has an static op_Equality
member defined, then "type == type" should always compile to a call to
that op_Equality member. This has always been the case for value types
(AFAICT) but isn't the case for String. I might do some more research to
see whether this mapping occurs for any heap objects.

Cheers,
--
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 :-)