.NET Forum / .NET Framework / New Users / August 2004
Strings.. Objects or not???
|
|
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 MagazinesGet 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 ...
|
|
|