By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,144 Members | 1,250 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,144 IT Pros & Developers. It's quick & easy.

compare string

P: n/a
Hello!

Below I have two different ways to test if the instance tb.Text contains the
string "Programmer"

So which one to use is it just a matter of taste ?
Or could it be some advantage to one before the other.
In a book I read they had used the second one but I prefer the first one
because it it clearer.

if (tb.Text == "Programmer")
{
......
}

if (tb.Text.CompareTo("Programmer")
{
......
}

//Tony
Jun 27 '08 #1
Share this Question
Share on Google+
11 Replies


P: n/a
On Tue, 24 Jun 2008 23:59:23 -0700, Tony <jo*****************@telia.com>
wrote:
Below I have two different ways to test if the instance tb.Text contains
the
string "Programmer"

So which one to use is it just a matter of taste ?
Or could it be some advantage to one before the other.
In a book I read they had used the second one but I prefer the first one
because it it clearer.
I would definitely not use "CompareTo()" just to test for equality. At
the very least, I'd use "Equals()". You didn't post code that was correct
enough to show just how awkward calling "CompareTo()" for this test would
really be. :)

That said, for strings I'd always just use the == operator. It justseems
more readable to me. Ironically, I think that for some people the
opposite would be true. They would feel that an English word is more
clear than a typographical symbol. To each his own. :)

And no, in the end I don't believe that there's any significant advantage
of one over the other. At best, there might be some subtle performance
difference, but undoubtedly not one large enough to warrant sacrificing
readability.

Pete
Jun 27 '08 #2

P: n/a
Hello!

You mentioned that using the CompareTo is really a bad choice and really
awkward.
Is it for some particularly reason that using the CompareTo is a bad choice
?
As I said I don't use it but as you sais I quote "You didn't post code that
was correct
enough to show just how awkward calling "CompareTo()" for this test would
really be. :)"

//Tony

"Peter Duniho" <Np*********@nnowslpianmk.comskrev i meddelandet
news:op***************@petes-computer.local...
On Tue, 24 Jun 2008 23:59:23 -0700, Tony <jo*****************@telia.com>
wrote:
Below I have two different ways to test if the instance tb.Text contains
the
string "Programmer"

So which one to use is it just a matter of taste ?
Or could it be some advantage to one before the other.
In a book I read they had used the second one but I prefer the first one
because it it clearer.
I would definitely not use "CompareTo()" just to test for equality. At
the very least, I'd use "Equals()". You didn't post code that was correct
enough to show just how awkward calling "CompareTo()" for this test would
really be. :)

That said, for strings I'd always just use the == operator. It just seems
more readable to me. Ironically, I think that for some people the
opposite would be true. They would feel that an English word is more
clear than a typographical symbol. To each his own. :)

And no, in the end I don't believe that there's any significant advantage
of one over the other. At best, there might be some subtle performance
difference, but undoubtedly not one large enough to warrant sacrificing
readability.

Pete
Jun 27 '08 #3

P: n/a
if the instance tb.Text contains the string "Programmer"

Personally, since I value the right result as much as clarity, I'd
probably go for:

if(tb.Text.Contains("Programmer")) {...}

Marc
Jun 27 '08 #4

P: n/a
On Jun 25, 8:14*am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
That said, for strings I'd always just use the == operator. *It just seems *
more readable to me. *Ironically, I think that for some people the *
opposite would be true. *They would feel that an English word is more *
clear than a typographical symbol. *To each his own. *:)
Slightly aside from Tony's original point, but...

There's one other important thing to think about when it comes to
string equality - what *kind* of string equality you want.

If you use a == b or just a.Equals(b) it will use ordinal comparison -
in other words, if the sequence of chars in a isn't exactly the same
as in b, it will return false.
If you want cultural equivalence or anything similar, you need the
overload of Equals which accepts a StringComparison.

See http://msdn.microsoft.com/en-us/library/ms973919.aspx for much
more detail and advice.

Jon
Jun 27 '08 #5

P: n/a
Re my last post - ignore that ;-p we might have been using different
meanings of "contains" - i.e. I'll guess you mean "contains *just* the
string ..."; sorry for any confusion.

Re CompareTo(), this returns an int, not a bool; you'd need to check
== 0, which doesn't make it very obvious what it is doing. Equals
would be much clearer.

Marc
Jun 27 '08 #6

P: n/a
Equals would be much clearer.
I'm not having a good day... I meant "much clearer than CompareTo";
for routine tests I'd just use == and for specific tests I'd use the
static methods such as string.Equals("foo","bar",
StringComparison.InvariantCultureIgnoreCase) - that way I don't need
to worry about whether the first or second arg is null.

Marc
Jun 27 '08 #7

P: n/a
Hello!

I tested these and found that Programmer was written.
This method Equals is comparing references as default but for this instance
tb which has been cast to TextBox has overriden this I assume in
the same way as == compare strings for equality
This literal string is placed somewhere in memory and a reference is
pointing to it. We call this ref_1
The other object tb is also a referenc to an TextBox object.We call this
ref_2.
If this ref_1 is the same as ref_2 then they are refering to the same
object.
But because Equal for TextBox don't compare references it compare the
value(string)
they are the same.

Have I understodd this correct ?
if (tb.Text.Equals("Programmer"))
{
Console.WriteLine("Programmer");
}

//Tony

"Jon Skeet [C# MVP]" <sk***@pobox.comskrev i meddelandet
news:d8**********************************@d45g2000 hsc.googlegroups.com...
On Jun 25, 8:14 am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
That said, for strings I'd always just use the == operator. It just seems
more readable to me. Ironically, I think that for some people the
opposite would be true. They would feel that an English word is more
clear than a typographical symbol. To each his own. :)
Slightly aside from Tony's original point, but...

There's one other important thing to think about when it comes to
string equality - what *kind* of string equality you want.

If you use a == b or just a.Equals(b) it will use ordinal comparison -
in other words, if the sequence of chars in a isn't exactly the same
as in b, it will return false.
If you want cultural equivalence or anything similar, you need the
overload of Equals which accepts a StringComparison.

See http://msdn.microsoft.com/en-us/library/ms973919.aspx for much
more detail and advice.

Jon
Jun 27 '08 #8

P: n/a
On Jun 25, 9:30*am, "Tony" <johansson.anders...@telia.comwrote:
I tested these and found that Programmer was written.
This method Equals is comparing references as default but for this instance
tb which has been cast to TextBox has overriden this I assume in
the same way as == compare strings for equality
No, because you're not comparing the TextBox for equality. You're
asking the TextBox for its Text property, which is just a string.
Nothing cares where the string came from.
This literal string is placed somewhere in memory and a reference is
pointing to it. We call this ref_1
The other object tb is also a referenc to an TextBox object.We call this
ref_2.
If this ref_1 is the same as ref_2 then they are refering to the same
object.
But because Equal for TextBox don't compare references it compare the
value(string)
they are the same.

Have I understodd this correct ?
No. If you'd written:

if (tb.Equals("Programmer"))

then it would have returned false - you'd be comparing a string with a
TextBox. As it is, you're comparing tb.Text and "Programmer", and both
of those expressions are strings.

Jon
Jun 27 '08 #9

P: n/a
Jon,

Reading the message from Tony, I thought what is he doing, this is meat for
Jons mouth, we get now a long reply about constants, immutability and more
of those things.

Was is with you, are you a little bit ill, I hope not. I saw noting in your
reply about that.

A property in the textbox.Text can in my idea never be the same as the
constant in the equal method.
Then that should be as well a property.

But you can explain this in my idea favorite of you more complete then me.

:-)

Cor

Jun 27 '08 #10

P: n/a
Cor Ligthert[MVP] <no************@planet.nlwrote:
Reading the message from Tony, I thought what is he doing, this is meat for
Jons mouth, we get now a long reply about constants, immutability and more
of those things.

Was is with you, are you a little bit ill, I hope not. I saw noting in your
reply about that.

A property in the textbox.Text can in my idea never be the same as the
constant in the equal method.
Then that should be as well a property.

But you can explain this in my idea favorite of you more complete then me.
I don't see anything in Tony's post which would make me talk about
immutability or constants. He'd simply been confused "comparing a
TextBox and a string" with "comparing the Text property of a TextBox,
and a string".

I can't think why you'd expect me to be talking about immutability or
constants.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com
Jun 27 '08 #11

P: n/a
Tonny,

snip
Have I understodd this correct ?
snip

Yes

To explain a little bit more:

Comparing strings does never compare references.

Your string can be endless time in memory, it has just is special kind of
behaviour.

Any little change to a string does create another string, becasuse every
string is immutable.

So comparing a string will never tell if it is in memory the same string,
however who cares, you and me are probably not able to create two strings
who consumes 100 kb of memory which are the same.

Cor

"Tony" <jo*****************@telia.comschreef in bericht
news:eD**************@TK2MSFTNGP06.phx.gbl...
Hello!

I tested these and found that Programmer was written.
This method Equals is comparing references as default but for this
instance
tb which has been cast to TextBox has overriden this I assume in
the same way as == compare strings for equality
This literal string is placed somewhere in memory and a reference is
pointing to it. We call this ref_1
The other object tb is also a referenc to an TextBox object.We call this
ref_2.
If this ref_1 is the same as ref_2 then they are refering to the same
object.
But because Equal for TextBox don't compare references it compare the
value(string)
they are the same.

Have I understodd this correct ?
if (tb.Text.Equals("Programmer"))
{
Console.WriteLine("Programmer");
}

//Tony

"Jon Skeet [C# MVP]" <sk***@pobox.comskrev i meddelandet
news:d8**********************************@d45g2000 hsc.googlegroups.com...
On Jun 25, 8:14 am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
>That said, for strings I'd always just use the == operator. It just seems
more readable to me. Ironically, I think that for some people the
opposite would be true. They would feel that an English word is more
clear than a typographical symbol. To each his own. :)

Slightly aside from Tony's original point, but...

There's one other important thing to think about when it comes to
string equality - what *kind* of string equality you want.

If you use a == b or just a.Equals(b) it will use ordinal comparison -
in other words, if the sequence of chars in a isn't exactly the same
as in b, it will return false.
If you want cultural equivalence or anything similar, you need the
overload of Equals which accepts a StringComparison.

See http://msdn.microsoft.com/en-us/library/ms973919.aspx for much
more detail and advice.

Jon

Jun 27 '08 #12

This discussion thread is closed

Replies have been disabled for this discussion.