views:

327

answers:

3

This question sounds outrageous, but VS is giving me an error when I check that a string length is greater than zero:

options[j]["pdprice"].ToString().Length > 0

Saying:

CS0019: Operator '>' cannot be applied to operands of type 'string' and 'int'

Can someone please explain why I cannot check that an integer length property is greater than zero? I even tried casting the entire thing as an int, but it still complains.

EDIT:

I like the answer below and will change the code. This is the original slightly modified to "work":

newlistitem.Value = options[j][valuefield].ToString() + 
((options[j]["pdprice"].ToString().Length > 0 ) ?  
"/" + options[j]["pdprice"].ToString() : "" );

And yes, it is referencing an old DataSet. We haven't had time to convert the solution to MVC, Linq, etc., but we are working on it. :)

+12  A: 

I'm not sure why you're seeing this particular error. But I can say you're doing this wrong. Here's the correct way to check for an empty string in .Net:

String.IsNullOrEmpty( options[j]["pdprice"].ToString() )

Note that this doesn't use a '>' operator anywhere, so at very least it's likely to give you a better error message.

Joel Coehoorn
Wouldn't it be better to do `Convert.ToString(options[j]["pdprice"])` just in case `options[j]["pdprice"]` is null?
Bob
@Bob, No. The above code handles the null cases just fine.
Simucal
No, Bob is right. I was thinking that looked like a dataset, which would typically use DBNull. But there's no guarantee that's what he has and null.ToString() does throw an exception. Still, he's presumably already tested the null part or he wouldn't be checking .Length.
Joel Coehoorn
@Simucal, how can you know that? What is **options[j]["pdprice"]**? If it evaluates to null, then the ToString() method will blow up.
John Fisher
Does this really answer his question? It appears to provide a solution, but without answering his actual question.
John Fisher
@John: This is just an example, it is the OP's responsibility to check for nulls.
Ed Swangren
+2  A: 

Your posted code doesn't contain an actual statement. So, it is reasonable for us to conclude that missing code is confusing the compiler. Make sure the syntax of code immediately around it is correct.

John Fisher
Note that it is impossible to confuse the compiler. The compiler has strict syntax rules it adheres to and it will never be confused, except when you ask it to resolve identifiers that have multiple meanings. In those cases, the compiler will complain. But it will never be confused and do the wrong thing, it will always do the right thing. The problem is always the programmer.
Lasse V. Karlsen
@Lasse - Sure, the problem is always the programmer. But, you're wrong in that it is impossible to confuse the compiler -- because programmers created the compiler. I haven't confused the C# compiler lately, but I clearly remember confusing compilers in the past (using proper syntax).
John Fisher
+8  A: 

I'm going to hazard a guess that your statement that the code is "slightly modified to work" means that this code:

newlistitem.Value = options[j][valuefield].ToString() + 
((options[j]["pdprice"].ToString().Length > 0 ) ?  
"/" + options[j]["pdprice"].ToString() : "" );

actually looked like this:

newlistitem.Value = options[j][valuefield].ToString() + 
options[j]["pdprice"].ToString().Length > 0  ?
"/" + options[j]["pdprice"].ToString() : "";

(note the missing parenthesis)

The reason that this code will produce this error is that due to operator precedence, what will get evaluated is this:

String  a = options[j][valuefield].ToString();
Int32   b = options[j]["pdprice"].ToString().Length;
String  c = a + b;
Boolean d = c > 0;
String  e = "/" + options[j]["pdprice"].ToString();
String  f = "";
newlistitem.value = d ? e : f;

With this way of looking at it, a+b will produce a new string, since adding something to a string will convert that something to a string for concatenation. Basically, "xyz" + 3 gives "xyz3".

By adding the parenthesis, your "slight modification", you've essentially rewritten the code to do this:

String  a = options[j][valuefield].ToString();
String  b = options[j]["pdprice"].ToString().Length;
Boolean c = b > 0;                                    <-- this is different
String  d = "/" + options[j]["pdprice"].ToString();
String  e = "";
String  f = c ? d : e;
String  g = a + f;                                    <-- and this
newlistitem.value = g;

Notice the difference between d in the first code and c in the second code. You've moved the concatenation of the string out where it belongs, together with the other strings.

So your slight modification works since it is the correct way of doing it, if you want to keep those expressions.

The accepted answer is a much better alternative. My goal was to give you an explanation as to the reason of the exception.

Lasse V. Karlsen
Excellent answer! The real one that explains the problem instead of just to find a workaround. Here the link with operators precedence in .NET: http://msdn.microsoft.com/en-us/library/6a71f45d.aspx
Kamarey