Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / August 2004

Tip: Looking for answers? Try searching our database.

Strings.. Objects or not???

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Rigga - 09 Jul 2004 12:30 GMT
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.
Herfried K. Wagner [MVP] - 09 Jul 2004 12:58 GMT
* "Rigga" <s@v.c> scripsit:
> I am wondering why string's are not true objects?.... Let me explain...
>
[quoted text clipped - 15 lines]
> Is this correct behavior??? if so is it true then that strings are not true
> objects?

Why not?  Both string objects are pointing to the same "constant".

Signature

Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/

Lucky Carl - 11 Jul 2004 04:45 GMT
> * "Rigga" <s@v.c> scripsit:
>> I am wondering why string's are not true objects?.... Let me explain...
[quoted text clipped - 18 lines]
>
> Why not?  Both string objects are pointing to the same "constant".

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/
Jon Skeet [C# MVP] - 11 Jul 2004 06:58 GMT
> Ok, so if
>
[quoted text clipped - 5 lines]
>
> Man.  Talk about /overhead/

It's done once per string, and I suspect it looks at the length and
hash of the string first.

So no, not that much overhead, really. Just how many string literals do
you have in your programs, anyway?

Signature

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

Nick Malik - 11 Jul 2004 09:36 GMT
It's done by the JIT Compiler... read the last word: COMPILER

It is done AT COMPILE TIME.

For a few milliseconds spent, the system saved me a little bit of memory.
Time well spent, I'd say.

--- Nick

> > * "Rigga" <s@v.c> scripsit:
> >> I am wondering why string's are not true objects?.... Let me explain...
[quoted text clipped - 28 lines]
>
> Man.  Talk about /overhead/
Herfried K. Wagner [MVP] - 11 Jul 2004 10:45 GMT
* Lucky Carl <carl.zafph@yahoo.no.spam> scripsit:
>>> Dim x1 as String = "veg"
>>> Dim x2 as String = "veg"
[quoted text clipped - 23 lines]
>
> Man.  Talk about /overhead/

I don't think that this is the case.  Instead, I assume that the scanner
will add the string literals to a symbol table and create according references
to the symbols in the table if a string literal occurs more than once.

Signature

Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/

Cor Ligthert - 11 Jul 2004 12:12 GMT
Hi Herfried,

Of course is it takes time.  When I see this kind of remarks, I always think
that those people who tell this are still thinking from an Ms-DOS kind of
operating systems without GUI. A GUI takes much more from an OS than those
loops in a simple table (that can even be optimized of course as you said).

We know that the immutability of a string takes time, thinking about that we
know that it takes maybe even more time than we think. (By the way, testing
for an existence is only needed when creating a string).

However, dotNet is not made for a Commodore 64 and even not for a PC1.

Just my thought about this.

Cor
One Handed Man \( OHM - Terry Burns \) - 11 Jul 2004 13:37 GMT
Hey I heard that they are bringing out Sinclair Spectrum.NET

LOL

Signature

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

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

> Hi Herfried,
>
[quoted text clipped - 12 lines]
>
> Cor
Jon Skeet [C# MVP] - 11 Jul 2004 20:49 GMT
> We know that the immutability of a string takes time, thinking about
> that we know that it takes maybe even more time than we think. (By
> the way, testing for an existence is only needed when creating a
> string).

Be careful here - the immutability of strings doesn't take any
resources at all; it's just a feature of there being no public methods
which change the contents. Interning of string literals is a separate
feature. While it requires immutability in order to be useful,
immutability doesn't require interning.

Signature

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

Cor Ligthert - 11 Jul 2004 21:16 GMT
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
One Handed Man \( OHM - Terry Burns \) - 12 Jul 2004 07:54 GMT
Cor is right.

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

Signature

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

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

> Jon,
>
[quoted text clipped - 5 lines]
>
> Cor
Jon Skeet [C# MVP] - 12 Jul 2004 10:07 GMT
> Cor is right.

I disagree.

> 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

But the point is that that is due to interning, not due to
immutability. Consider a system where strings were immutable, but
weren't interned: where would the slowdown be?

I don't disagree that there *is* a performance penalty (although I
believe it's insignificant). I disagree with the idea that that penalty
is due to immutability rather than due to interning.

Signature

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

One Handed Man \( OHM - Terry Burns \) - 12 Jul 2004 17:29 GMT
Immutability has nothing to do with performance of string matching. I was
simply making a point about the matching itself.

Signature

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

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

> > Cor is right.
>
[quoted text clipped - 11 lines]
> believe it's insignificant). I disagree with the idea that that penalty
> is due to immutability rather than due to interning.
Jon Skeet [C# MVP] - 12 Jul 2004 18:26 GMT
> Immutability has nothing to do with performance of string matching.

Indeed.

> I was simply making a point about the matching itself.

And that's why I was surprised when you agreed with Cor who seemed to
be making a point about immutability...

Signature

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

One Handed Man \( OHM - Terry Burns \) - 12 Jul 2004 19:38 GMT
When I agreed, it was in respect of matching performance, I must have missed
that.

Signature

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

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

> > Immutability has nothing to do with performance of string matching.
>
[quoted text clipped - 4 lines]
> And that's why I was surprised when you agreed with Cor who seemed to
> be making a point about immutability...
Cor Ligthert - 12 Jul 2004 20:08 GMT
Hi Jon,

> And that's why I was surprised when you agreed with Cor who seemed to
> be making a point about immutability...

This is not cricket,

Do not tell things about me, that I have to see by accident. You put words
in my mouth I never said.

A string in this situation is nothing more than address (length) where the
address is the address of a pool of different strings without redundancy.

Happy with this?

Cor
Jon Skeet [C# MVP] - 12 Jul 2004 22:10 GMT
> > And that's why I was surprised when you agreed with Cor who seemed to
> > be making a point about immutability...
[quoted text clipped - 3 lines]
> Do not tell things about me, that I have to see by accident. You put words
> in my mouth I never said.

Note the "seemed to". To me, you seemed to be making a point about
immutability.

> A string in this situation is nothing more than address (length) where the
> address is the address of a pool of different strings without redundancy.
>
> Happy with this?

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

Signature

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

Cor Ligthert - 13 Jul 2004 07:30 GMT
> 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] - 13 Jul 2004 08:02 GMT
> > 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.

Signature

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

Cor Ligthert - 13 Jul 2004 08:57 GMT
Jon,

> For instance, in C#:
>
[quoted text clipped - 8 lines]
> 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] - 13 Jul 2004 09:54 GMT
> > For instance, in C#:
> >
[quoted text clipped - 8 lines]
> > 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.

Signature

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

Cor Ligthert - 13 Jul 2004 10:56 GMT
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] - 13 Jul 2004 11:10 GMT
> > No, they're strings (or rather, string references).
> > StringBuilder.ToString() returns a string. The StringBuilder object
[quoted text clipped - 12 lines]
> 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.
[quoted text clipped - 6 lines]
> 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?

Signature

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

Cor Ligthert - 13 Jul 2004 11:30 GMT
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] - 13 Jul 2004 11:45 GMT
> > 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
[quoted text clipped - 7 lines]
> 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>

Signature

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

Cor Ligthert - 13 Jul 2004 12:04 GMT
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] - 13 Jul 2004 19:16 GMT
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
[quoted text clipped - 9 lines]
>>
>> Cor
Jon Skeet [C# MVP] - 12 Jul 2004 10:05 GMT
> We know that the immutability of a string takes time

In what way? How does immutability itself take time?

> thinking about this subject we know that it takes maybe even
> more time than we think to create a string.
>
> So better?

Not really, no.

Signature

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

Cor Ligthert - 12 Jul 2004 10:21 GMT
Thirth try,

We know that the immutability of a string can take more time when we concate
them when we do not use the stringbuilder, thinking about this subject we
know that it can take even more time than we maybe think to create a string.

Can this have your agreement?

:-)

(You would already know from me that as I wrote again in this thread that
this kind of needed time is real bs for me)

:-)

Cor
Jon Skeet [C# MVP] - 12 Jul 2004 10:48 GMT
> Thirth try,
>
[quoted text clipped - 3 lines]
>
> Can this have your agreement?

Sort of. However, immutability also speeds things up as you don't need
to copy strings all over the place just to make sure they don't change.
Immutability itself doesn't cost anything - it's not like the CLR has
to do anything special with an object just because it's immutable. The
impact of immutability on the API (for example, concatenating strings)
can cost time and save time, depending on what you're doing.

Signature

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

Cor Ligthert - 12 Jul 2004 17:08 GMT
Hi Jon,

> > Can this have your agreement?
>
[quoted text clipped - 4 lines]
> impact of immutability on the API (for example, concatenating strings)
> can cost time and save time, depending on what you're doing.

I have to go back very much time in memory, I though that we wrote than a
string something like this S(length). And it was ofcours mutable. The
approach of the constant (which I did not know before I saw this message) is
for me something the same as the not redundant database, it is nice however
cost time.

For the rest I refer to the message from OHM and Guy which gave me as well
some insight in this problem.

I hope that you do not mind that we make this EOT, my purpose from my first
message was an answer to Lucky which seems to me to come from a special
area, however I did not wanted to answer it to direct.

And than as for ever, I have to answer Jon, (not offended ment just for
fun).

:-)

Cor
Jon Skeet [C# MVP] - 12 Jul 2004 17:24 GMT
> > > Can this have your agreement?
> >
[quoted text clipped - 4 lines]
> > impact of immutability on the API (for example, concatenating strings)
> > can cost time and save time, depending on what you're doing.

> I have to go back very much time in memory, I though that we wrote than a
> string something like this S(length). And it was ofcours mutable.

What do you mean by "we wrote"?

> The approach of the constant (which I did not know before I saw this
> message) is for me something the same as the not redundant database,
> it is nice however cost time.

String literal interning costs time, yes. (We agree that the amount of
time is almost always insignificant.) That's not the same as
immutability though - you seem to be switching from one to the other
all the time as if they're the same thing.

> For the rest I refer to the message from OHM and Guy which gave me as well
> some insight in this problem.

They both seem to be talking about interning, too - not immutability.

> I hope that you do not mind that we make this EOT, my purpose from my first
> message was an answer to Lucky which seems to me to come from a special
> area, however I did not wanted to answer it to direct.

The problem was that your answer to Lucky talked about immutability,
when Lucky was talking about interning. That's why I replied to your
post - you seemed to be confusing the two, even if you actually
weren't.

Signature

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

Cor Ligthert - 12 Jul 2004 17:41 GMT
>We

The programmers in those very old days in the old big king mainframe
assembler time (however as I told, I am not even sure anymore of that
statement so do not arguing about that, I will loose at the start).

> The problem was that your answer to Lucky talked about immutability,
> when Lucky was talking about interning. That's why I replied to your
> post - you seemed to be confusing the two, even if you actually
> weren't.

That was why I tried to make two times a correction, did I make any
statement of disagrement with you about that or do you think that I am to
afraid to do that to you?

:-)

Cor
Jon Skeet [C# MVP] - 12 Jul 2004 18:28 GMT
> >We
>
> The programmers in those very old days in the old big king mainframe
> assembler time (however as I told, I am not even sure anymore of that
> statement so do not arguing about that, I will loose at the start).

Ah. I see what you mean now. Some frameworks certainly have mutable
strings, yes.

> > The problem was that your answer to Lucky talked about immutability,
> > when Lucky was talking about interning. That's why I replied to your
[quoted text clipped - 4 lines]
> statement of disagrement with you about that or do you think that I
> am to afraid to do that to you?

The first time you corrected it was fine - but then in that previous
post you seemed to be confusing them again. Maybe you were, maybe you
weren't - it wasn't very clear.

Signature

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

Cor Ligthert - 12 Jul 2004 19:58 GMT
> > Do you think that I am to afraid to do that to you?
>
> Maybe you were, maybe you weren't - it wasn't very clear.

No I am not, do not make yourself any illusion.

:-))))

A little bit constructive quoting before you say it, about the other point
because of this discussion I become more and more to disagree with you, I
cannot see the string creation as a part of different things, however see it
more and more as a method and a storage item, thight together like in every
OOP situation. However Jon, not something what I like to argue about, that
was long ago that I liked it to make things as this more clear for me. When
I needed that it is more clear, I will investigate it, so sorry I only say
in this one "I agree with you".

Cor
David - 03 Aug 2004 22:19 GMT
> Ok, so if
>
[quoted text clipped - 5 lines]
>
> Man.  Talk about /overhead/

Sure, but it's compile-time overhead.  Which isn't really a big deal.
Lance Wynn - 09 Jul 2004 14:00 GMT
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.  If your using C#, you can overload
operators for your own classes, and make them behave the same way.

Lance

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 - 03 Aug 2004 22:26 GMT
> 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 - 03 Aug 2004 22:37 GMT
[Strings]

> Dim s as String = "123"
> Dim s2 as String = "1234"
[quoted text clipped - 7 lines]
> 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.

Signature

Chris Mullins

Peter Bromley - 03 Aug 2004 23:00 GMT
>>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
[quoted text clipped - 13 lines]
>     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....

Signature

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 - nospam@nowhere.com  :-)

David - 04 Aug 2004 03:26 GMT
>>>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
[quoted text clipped - 17 lines]
>
> 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 - 04 Aug 2004 23:00 GMT
>>So the lesson here is don't ever use the '=' Operator with strings.
>>
[quoted text clipped - 4 lines]
> 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
[quoted text clipped - 8 lines]
>
> 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?

Signature

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 - nospam@nowhere.com  :-)

Jon Skeet [C# MVP] - 05 Aug 2004 08:38 GMT
> Perhaps there is some difference between VB and C++ but I was
> conclusively bitten by my assumption that == and .Equals did the same
[quoted text clipped - 9 lines]
> 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).

Signature

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

Peter Bromley - 05 Aug 2004 22:38 GMT
>>Perhaps there is some difference between VB and C++ but I was
>>conclusively bitten by my assumption that == and .Equals did the same
[quoted text clipped - 14 lines]
> 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,

Signature

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 - nospam@nowhere.com  :-)

David - 05 Aug 2004 12:07 GMT
>> It does behave as the Equals method. In the above example,
>>
[quoted text clipped - 7 lines]
> 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";
[quoted text clipped - 7 lines]
>
> 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.
Rigga - 09 Jul 2004 14:35 GMT
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.

> Hi all,
>
[quoted text clipped - 21 lines]
>
> Rigga.
Jon Skeet [C# MVP] - 09 Jul 2004 14:44 GMT
> Thanks all for your replies but I'm still confused.
>
[quoted text clipped - 18 lines]
>
> Anyway, now that I know this I'll have to code around it.. thanks all..

String behaves like other objects for the most part, but string
literals are interned automatically, so that within a single AppDomain,
all references to the same string literal are references to the same
actual string.

One *really* weird bit about string is that if you create a new string
using the char[] constructor, but give it an empty array, it doesn't
actually create a new string at all - it just returns String.Empty.
Very odd indeed.

Signature

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

Patrick Steele [MVP] - 09 Jul 2004 14:52 GMT
> Thanks all for your replies but I'm still confused.
>
> So coding "veg" anywhere will only ever create one object?

Yes.  It's called "String Interning" and the String.Intern method has a
description of what it's for.  Basically (from the docs):

"The common language runtime conserves string storage by maintaining a
table, called the intern pool, that contains a single reference to each
unique literal string declared or created programmatically in your
program. Consequently, an instance of a literal string with a particular
value only exists once in the system."

Signature

Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele

Herfried K. Wagner [MVP] - 09 Jul 2004 15:34 GMT
* Patrick Steele [MVP] <patrick@mvps.org> scripsit:
>> Thanks all for your replies but I'm still confused.
>>
[quoted text clipped - 8 lines]
> program. Consequently, an instance of a literal string with a particular
> value only exists once in the system."

Just to add that this is a common design approach, that has been taken in
VB6 too, for example.

Signature

Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/

Cor Ligthert - 09 Jul 2004 15:01 GMT
Hi Rigga,

Yes it is an object. (However for the rest nothing to add to Jon's
explanation)

Cor
One Handed Man \( OHM - Terry Burns \) - 09 Jul 2004 17:01 GMT
Hey. dont ever change your second name to 'Mortis' !

LOL

Signature

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

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

> Thanks all for your replies but I'm still confused.
>
[quoted text clipped - 47 lines]
> >
> > Rigga.
Cowboy \(Gregory A. Beamer\) [MVP] - 09 Jul 2004 19:58 GMT
See the app I posted in reponse to your intial question. The test app should
give you an idea of what is happening.

Signature

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

> Thanks all for your replies but I'm still confused.
>
[quoted text clipped - 47 lines]
> >
> > Rigga.
Michael G W - 13 Jul 2004 06:03 GMT
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.

> Thanks all for your replies but I'm still confused.
>
[quoted text clipped - 47 lines]
> >
> > Rigga.
Jon Skeet [C# MVP] - 13 Jul 2004 08:04 GMT
<"=?Utf-8?B?TWljaGFlbCBHIFc=?=" <Michael G
W@discussions.microsoft.com>> wrote:
> This thread seems to have gone off on tangents everythere.
>
[quoted text clipped - 4 lines]
> 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.

Signature

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

Jay B. Harlow [MVP - Outlook] - 09 Jul 2004 15:47 GMT
Rigga,
In addition to the other comments.

Try the following:

       Dim x1 As String = "veggie"
       Dim x2 As String = "veg"

       x1 = x1.Substring(0, 3)

       If x1 = x2 Then
           Debug.WriteLine("i expect this code to be executed")
       End If

       If x1 Is x2 Then
           Debug.WriteLine("i do not expect this code to be executed")
       End If

Both strings contain "veg", however because the second one was "calculated"
instead of being a constant it is a different string object on the heap.

You can use String.Copy to create a new instances of a string.

       Dim x1 As String = "veg"
       Dim x2 As String = String.Copy(x1)

Note String.Clone returns the same instance...

Hope this helps
Jay

> Hi all,
>
[quoted text clipped - 21 lines]
>
> Rigga.
Cowboy \(Gregory A. Beamer\) [MVP] - 09 Jul 2004 19:55 GMT
The compiler recognizes you setting it to the same string and creates IL
that points to a single spot in memory. Run this test as a console
application and it will become crystal clear:

Module Module1

   Private veg As String = "veg"

   Sub Main()
       Test1()
       Test2()
       Test3()

       Console.Read()
   End Sub

   Sub Test1()
       Console.WriteLine("TEST 1")
       Console.WriteLine("-------------")

       Dim x1 As String = "veg"
       Dim x2 As String = "veg"

       If x1 = x2 Then
           Console.WriteLine("x1 = x2")
       End If

       If x1 Is x2 Then
           Console.WriteLine("x1 is x2")
       End If

       Console.WriteLine("")
   End Sub

   Sub Test2()
       Console.WriteLine("TEST 2")
       Console.WriteLine("-------------")

       Dim x1 As String = veg
       Dim x2 As String = veg

       If x1 = x2 Then
           Console.WriteLine("x1 = x2")
       End If

       If x1 Is x2 Then
           Console.WriteLine("x1 is x2")
       End If

       Console.WriteLine("")
   End Sub

   Sub Test3()
       Console.WriteLine("TEST 3")
       Console.WriteLine("-------------")

       Dim sb As New Text.StringBuilder

       sb.Append("v")
       sb.Append("e")
       sb.Append("g")

       Dim x1 As String = "veg"
       Dim x2 As String = sb.ToString()

       If x1 = x2 Then
           Console.WriteLine("x1 = x2")
       End If

       If x1 Is x2 Then
           Console.WriteLine("x1 is x2")
       End If

       Console.WriteLine("")
   End Sub

End Module

Signature

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

> Hi all,
>
[quoted text clipped - 21 lines]
>
> Rigga.
Abubakar - 24 Jul 2004 11:15 GMT
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

> Hi all,
>
[quoted text clipped - 21 lines]
>
> Rigga.
Bob Grommes - 28 Jul 2004 21:00 GMT
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

> 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.
[quoted text clipped - 29 lines]
> >
> > Rigga.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.