compare string

  • Thread starter Thread starter Tony
  • Start date Start date
T

Tony

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
 
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
 
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
 
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" <[email protected]> skrev i meddelandet
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
 
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
 
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
 
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]" <[email protected]> skrev i meddelandet
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
 
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
 
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
 
Cor Ligthert said:
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.
 
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 said:
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]" <[email protected]> skrev i meddelandet
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top