469,898 Members | 1,611 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,898 developers. It's quick & easy.

Strings.. Objects or not???

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.
Nov 20 '05 #1
73 2525
* "Rigga" <s@v.c> scripsit:
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?


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

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #2
I don't buy it... it seems odd to me as well. Using the IS operator
indicates that the pointer, living on the stack, points to the object on
the heap. At least that is how I always picture it...

This behavior makes me think that "veg" is on the heap, and both x1 ans
x2 are pointing to that... BUT if this were truely the case, changing X1
to "beef" would also change X2, which of course does not happen.

Does it actually create a third object, as you mention, a constant, on
the heap and point to that? then when I say x2="beef" it creates a
second constant object on the heap and points x2 to it, therefore x1 IS
no longer x2....?

I'd love to hear some more discussion on this question...

--Zorpy

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 20 '05 #3
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

"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.

Nov 20 '05 #4
David Williams <Da***********@discussions.microsoft.com> wrote:
Remember that strings are ValueTypes, not ReferenceTypes.


No they're not. They're reference types. There are any numbers of ways
to verify that, but Type.IsValueType is probably the easiest.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 20 '05 #5
* ZorpiedoMan <No********@Beatles.com> scripsit:
I don't buy it... it seems odd to me as well. Using the IS operator
indicates that the pointer, living on the stack, points to the object on
the heap. At least that is how I always picture it...

This behavior makes me think that "veg" is on the heap, and both x1 ans
x2 are pointing to that... BUT if this were truely the case, changing X1
to "beef" would also change X2, which of course does not happen.


String is a reference type. If you have an object that is referenced by
two variables, changing the object that is referenced by one of the two
variables doesn't change the reference the other variable is pointing to.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #6
* "=?Utf-8?B?RGF2aWQgV2lsbGlhbXM=?=" <Da***********@discussions.microsoft.com> scripsit:
Remember that strings are ValueTypes, not ReferenceTypes.


No! Strings are not value types, they don't inherit from
'System.ValueType':

\\\
Dim s As String = "Hello World"
MsgBox(TypeOf s Is ValueType)
///

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #7
But let's not forget that they are immutable.... When you change the value
of a string object, the object is destroyed and a brand new one is created.

--
HTH,
-- Tom Spink, Über Geek

Woe be the day VBC.EXE says, "OrElse what?"

Please respond to the newsgroup,
so all can benefit
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2l************@uni-berlin.de...
* "=?Utf-8?B?RGF2aWQgV2lsbGlhbXM=?="

<Da***********@discussions.microsoft.com> scripsit:
Remember that strings are ValueTypes, not ReferenceTypes.


No! Strings are not value types, they don't inherit from
'System.ValueType':

\\\
Dim s As String = "Hello World"
MsgBox(TypeOf s Is ValueType)
///

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

Nov 20 '05 #8
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.

Nov 20 '05 #9
Hi Tom,

From you I had expected more, the question is (see it yourself) ..... And
now everybody telling that a string object is a reference type or something
like that.

:-)

Cor
Nov 20 '05 #10
Tom Spink <thomasdotspinkatsp@mntlworlddotcom> wrote:
But let's not forget that they are immutable.... When you change the value
of a string object, the object is destroyed and a brand new one is created.


Um, no. You *can't* "change the value" of a string object. You can
change the value of a variable so that it's a reference to a different
string, but that doesn't necessarily destroy the old string or create a
new one.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 20 '05 #11
Rigga <s@v.c> 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..


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 20 '05 #12
In article <40*********************@ptn-nntp-reader02.plus.net>, s@v.c
says...
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."

--
Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele
Nov 20 '05 #13
Hi Rigga,

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

Cor
Nov 20 '05 #14
* "Cor Ligthert" <no**********@planet.nl> scripsit:
From you I had expected more, the question is (see it yourself) ..... And
now everybody telling that a string object is a reference type or something
like that.


What would you have expected? It's similar to what's going on for all
the other reference types, so telling that string is a reference type
answers the question, IMO.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #15
I did place an answer below.

:-)

Cor
Nov 20 '05 #16
* Patrick Steele [MVP] <pa*****@mvps.org> scripsit:
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."


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

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #17
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

"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.

Nov 20 '05 #18
Hey. dont ever change your second name to 'Mortis' !

LOL

--

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

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

"Rigga" <s@v.c> wrote in message
news:40*********************@ptn-nntp-reader02.plus.net...
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.


Nov 20 '05 #19
Perhaps I should have quoted my "change" word... but MSDN says:

<MSDN>
A String is called immutable because its value cannot be modified once it
has been created. Methods that appear to modify a String actually return a
new String containing the modification. If it is necessary to modify the
actual contents of a string-like object, use the System.Text.StringBuilder
class.
</MSDN>

This is what I was referring to... whoops

--
HTH,
-- Tom Spink, Über Geek

Woe be the day VBC.EXE says, "OrElse what?"

Please respond to the newsgroup,
so all can benefit
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Tom Spink <thomasdotspinkatsp@mntlworlddotcom> wrote:
But let's not forget that they are immutable.... When you change the value of a string object, the object is destroyed and a brand new one is
created.
Um, no. You *can't* "change the value" of a string object. You can
change the value of a variable so that it's a reference to a different
string, but that doesn't necessarily destroy the old string or create a
new one.

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

Nov 20 '05 #20
This is very true, but does not explain what is happening. The compiler
sees:

Dim x as String = "veg"
Dim y as String = "veg"

and says "hey, it is the same constant." Underneath the hood, some magic
happens. NOTE: This is actually the JIT compiler that does this magic and
not the initial IL compile. Tres kewl!

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

************************************************
Think Outside the Box!
************************************************
"Tom Spink" <thomasdotspinkatsp@mntlworlddotcom> wrote in message
news:OS**************@TK2MSFTNGP12.phx.gbl...
But let's not forget that they are immutable.... When you change the value
of a string object, the object is destroyed and a brand new one is created.
--
HTH,
-- Tom Spink, Über Geek

Woe be the day VBC.EXE says, "OrElse what?"

Please respond to the newsgroup,
so all can benefit
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:2l************@uni-berlin.de...
* "=?Utf-8?B?RGF2aWQgV2lsbGlhbXM=?="

<Da***********@discussions.microsoft.com> scripsit:
Remember that strings are ValueTypes, not ReferenceTypes.


No! Strings are not value types, they don't inherit from
'System.ValueType':

\\\
Dim s As String = "Hello World"
MsgBox(TypeOf s Is ValueType)
///

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


Nov 20 '05 #21
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

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

************************************************
Think Outside the Box!
************************************************
"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.

Nov 20 '05 #22
See the app I posted in reponse to your intial question. The test app should
give you an idea of what is happening.

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

************************************************
Think Outside the Box!
************************************************
"Rigga" <s@v.c> wrote in message
news:40*********************@ptn-nntp-reader02.plus.net...
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.


Nov 20 '05 #23
Strings are reference types (objects) and not value types (structs). The
issue here lies completely in the compiler, not in the code. Test app:

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

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

************************************************
Think Outside the Box!
************************************************
"David Williams" <Da***********@discussions.microsoft.com> wrote in message
news:A5**********************************@microsof t.com...
Remember that strings are ValueTypes, not ReferenceTypes. Not only that, but as Herfried stated, due to the way that .NET optimizes strings, both of
those object reference the same IL constant. This is possible because
strings are immutable, i.e. they never change once created.
HTH
--
David Williams, VB.NET MVP
"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.

Nov 20 '05 #24
> Um, no. You *can't* "change the value" of a string object. You can

Well, you *can* do it, but most likely it'll mess things up in other
calculations on strings in your apps...

-mike

Nov 20 '05 #25
Michael Giagnocavo [MVP] <mg*******@atrevido.net> wrote:
Um, no. You *can't* "change the value" of a string object. You can


Well, you *can* do it, but most likely it'll mess things up in other
calculations on strings in your apps...


You can't do it in safe, managed code outside mscorlib which doesn't
use reflection - is that better? ;)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 20 '05 #26
* Lucky Carl <ca********@yahoo.no.spam> scripsit:
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?


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/


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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 20 '05 #27
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
Nov 20 '05 #28
Hey I heard that they are bringing out Sinclair Spectrum.NET

LOL

--

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****************@TK2MSFTNGP12.phx.gbl...
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

Nov 20 '05 #29
>> Well, you *can* do it, but most likely it'll mess things up in other
calculations on strings in your apps...


You can't do it in safe, managed code outside mscorlib which doesn't
use reflection - is that better? ;)


Sure, just wanted that to be clear :)

-mike
Nov 20 '05 #30
Cor Ligthert <no**********@planet.nl> wrote:
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.

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

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

Nov 20 '05 #32
I wouldn't mind being able to write the code - as I can in languages
like Ruby

"John".ToLower()

Since we are talking of what a string object is and what it isn't , why
is it that you can do something like

Dim s as String="John"
s.ToLower()

but not
"John".ToLower()?

Just a thought :-)
Sriram Krishnan
----------------------------------------------------
I blog at http://www.dotnetjunkies.com/weblog/sriram
-----------------------------------------------------
Nov 20 '05 #33
Sriram,
but not
"John".ToLower()? Who says you cannot? the above code is valid, compiles & executes on .NET
1.0, 1.1 & 2.0!

The "problem" you have in both your samples is you are ignoring the return
value! Remember that String.ToLower returns a new string that you need to
assign to a variable.

Try:

Dim s as String="John"
s = s.ToLower()
s = "JAY".ToLower()?

Hope this helps
Jay
"Sriram Krishnan" <ksriram@NOSPAMgmxDOTnet> wrote in message
news:ui**************@TK2MSFTNGP10.phx.gbl... I wouldn't mind being able to write the code - as I can in languages
like Ruby

"John".ToLower()

Since we are talking of what a string object is and what it isn't , why
is it that you can do something like

Dim s as String="John"
s.ToLower()

but not
"John".ToLower()?

Just a thought :-)
Sriram Krishnan
----------------------------------------------------
I blog at http://www.dotnetjunkies.com/weblog/sriram
-----------------------------------------------------

Nov 20 '05 #34
guy
err. doing this on an intel chip is a 1 (one) assembler instruction! I cant remeber the opcode, years since i used it, but on a Z80 (remember them?) the assembler instruction was CPIR i believe - hardy inefficient!

guy

"Lucky Carl" wrote:
Cowboy (Gregory A. Beamer) [MVP] wrote:
This is very true, but does not explain what is happening. The compiler
sees:

Dim x as String = "veg"
Dim y as String = "veg"

and says "hey, it is the same constant." Underneath the hood, some magic
happens. NOTE: This is actually the JIT compiler that does this magic and
not the initial IL compile. Tres kewl!


I hope whatever pattern matching algorithm for strings that is used is
efficient.

That means that any new string has to run through such a comparison to
determine whether it exists or not.

Whatever little bit of memory is conserved would seem small compared to the
amount of wasted cpu time in performing this operation.

Nov 20 '05 #35
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

--

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

Nov 20 '05 #36
Your showing your age, the Z80 came out around 1980, thats 24 years ago !

I remember because we used them in science club at school.

--

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

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

"guy" <gu*@discussions.microsoft.com> wrote in message
news:D0**********************************@microsof t.com...
err. doing this on an intel chip is a 1 (one) assembler instruction! I cant remeber the opcode, years since i used it, but on a Z80 (remember
them?) the assembler instruction was CPIR i believe - hardy inefficient!
guy

"Lucky Carl" wrote:
Cowboy (Gregory A. Beamer) [MVP] wrote:
This is very true, but does not explain what is happening. The compiler sees:

Dim x as String = "veg"
Dim y as String = "veg"

and says "hey, it is the same constant." Underneath the hood, some magic happens. NOTE: This is actually the JIT compiler that does this magic and not the initial IL compile. Tres kewl!


I hope whatever pattern matching algorithm for strings that is used is
efficient.

That means that any new string has to run through such a comparison to
determine whether it exists or not.

Whatever little bit of memory is conserved would seem small compared to the amount of wasted cpu time in performing this operation.

Nov 20 '05 #37
<"One Handed Man \( OHM - Terry Burns \)" <news.microsoft.com>> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 20 '05 #38
Cor Ligthert <no**********@planet.nl> wrote:
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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 20 '05 #39
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
Nov 20 '05 #40
Cor Ligthert <no**********@planet.nl> wrote:
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?


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 20 '05 #41
guy
aye laddie,
2Mhz solder in the resistors NASCOM, write your own (polling) diskcontrollers and it STILL runs today:-)

"One Handed Man ( OHM - Terry Burns )" wrote:
Your showing your age, the Z80 came out around 1980, thats 24 years ago !

I remember because we used them in science club at school.

--

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

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

"guy" <gu*@discussions.microsoft.com> wrote in message
news:D0**********************************@microsof t.com...
err. doing this on an intel chip is a 1 (one) assembler instruction! I

cant remeber the opcode, years since i used it, but on a Z80 (remember
them?) the assembler instruction was CPIR i believe - hardy inefficient!

guy

"Lucky Carl" wrote:
Cowboy (Gregory A. Beamer) [MVP] wrote:

> This is very true, but does not explain what is happening. The compiler > sees:
>
> Dim x as String = "veg"
> Dim y as String = "veg"
>
> and says "hey, it is the same constant." Underneath the hood, some magic > happens. NOTE: This is actually the JIT compiler that does this magic and > not the initial IL compile. Tres kewl!
>

I hope whatever pattern matching algorithm for strings that is used is
efficient.

That means that any new string has to run through such a comparison to
determine whether it exists or not.

Whatever little bit of memory is conserved would seem small compared to the amount of wasted cpu time in performing this operation.


Nov 20 '05 #42
Immutability has nothing to do with performance of string matching. I was
simply making a point about the matching itself.

--

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

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

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<"One Handed Man \( OHM - Terry Burns \)" <news.microsoft.com>> wrote:
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.

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

Nov 20 '05 #43
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
Nov 20 '05 #44
<"One Handed Man \( OHM - Terry Burns \)" <news.microsoft.com>> wrote:
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...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 20 '05 #45
Cor Ligthert <no**********@planet.nl> wrote:
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
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?


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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 20 '05 #46
When I agreed, it was in respect of matching performance, I must have missed
that.

--

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

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

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<"One Handed Man \( OHM - Terry Burns \)" <news.microsoft.com>> wrote:
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...

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

Nov 20 '05 #47
> > 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
Nov 20 '05 #48
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

Nov 20 '05 #49
Cor Ligthert <no**********@planet.nl> wrote:
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.


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.

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

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

42 posts views Thread by Rigga | last post: by
5 posts views Thread by Colin Savage | last post: by
10 posts views Thread by Ian Todd | last post: by
52 posts views Thread by Paddy | last post: by
74 posts views Thread by cman | last post: by
95 posts views Thread by hstagni | last post: by
1 post views Thread by Edward K Ream | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.