While doing this bool iteration, I was tempted to use the non existing operator ||=, and figured there must be a simpler or better design that would replace its valid use (rather than think it's just "missing"):
bool validExtension = false;
foreach (string extension in Plugin.Extensions)
{
validExtension = validExtension || Path.GetExtension(file).Equals(extension.TrimStart('*'), StringComparison.InvariantCultureIgnoreCase);
if (validExtension)
{
break;
}
}
importButton.Enabled = File.Exists(importTextBox.Text) && validExtension;
That loop has an invariant: on entry to the body, validExtension = false.
So the body can be simplified to:
if (validExtension = Path.GetExtension(file).Equals(extension.TrimStart('*'), StringComparison.InvariantCultureIgnoreCase))
break;
If there wasn't such an invariant, you could use the compound assignment operator |= if you always wanted to evaluate the right-hand side, or if (!lhs) lhs = rhs; if you wanted short-circuiting.
foreach (string extension in Plugin.Extensions)
{
if (Path.GetExtension(file).Equals(extension.TrimStart('*'), StringComparison.InvariantCultureIgnoreCase))
{
validExtension = true;
break;
}
}
This works because you are breaking the first time you find a valid extension, so validExtension is always false on the first line of the loop.
can't you just say validExtension = Path.Get.... since at the start of the expression validExtension will always be false.
While there is no ||= operator in C#, there is the |= operator that may be what you're looking for.
MSDN Reference
If its a string[], the whole code can be changed like this
Func<string[], string, bool> validExtension = (arr, s) => arr.Contains(s);
importButton.Enabled = validExtension(Plugin.Extensions, Path.GetExtension(file)) && File.Exists(importTextBox.Text);
For checking a value inside an Array you could always use Array.Contains extension method.
P.S: I have reversed the tests as Ben Voigt rightfully said
Related
I'm a student and I was wondering what the most efficient way is to check if a certain value is present in a array.
My second attempt:
string value = "pow";
string[] array = new string[] { "pong", "ping", "pow" };
bool valueIsInArray = false;
foreach(var s in array) if (s == value) valueIsInArray = true;
if (valueIsInArray)
{
// code here
}
I've researched and found if I were to use LINQ the code would look like this:
string value = "oink"; // value given to the method
string[] array = new string[] { "oink", "oink", "baboinkadoink" };
if (array.Contains(value))
{
//code here
}
The question is if using LINQ in anyway negatively impacts the speed or consistency of the code, and if there is an even better way to go about doing this?
Use linq Any(), The enumeration of source is stopped as soon as the result can be determined.
string value = "pow";
string[] array = new string[] { "pong", "ping", "pow" };
bool isValuePresent = array.Any(x => x == value);
https://msdn.microsoft.com/en-us/library/bb534972(v=vs.110).aspx
As a commenter said, LiNQ won't really trouble you here. The difference is microscopic (even on larger collections). However, if you must use an alternative, use IndexOf. See: https://msdn.microsoft.com/en-us/library/system.array.indexof(v=vs.110).aspx
Example:
string value = "oink"; // value given to the method
string[] array = new string[] { "oink", "oink", "baboinkadoink" };
if (Array.IndexOf(array, value) > -1)
{
//code here
}
Although I'm not sure what Contains ends up doing underwater, but they probably make a call to IndexOf aswell.
Willy-nilly you have to scan the array up to the first match (or entire array if there's no match); you can either put foreach loop:
bool valueIsInArray = false;
foreach (var item in array)
if (item == value) {
valueIsInArray = true;
break;
}
use for one:
bool valueIsInArray = false;
foreach (int i = 0; i < array.Length; ++i)
if (array[i] == value) {
valueIsInArray = true;
break;
}
Try Array class:
bool valueIsInArray = array.Contains(value);
Implement the code with a help of Linq:
bool valueIsInArray = array.Any(item => item == value);
The difference of these methods is a question of microseconds (if any); that's why put the version which is the most readable for you. My own choice is array.Contains(value) - let the system work for you and hide unwanted details (e.g. break in the loop)
You shoud have to iterate through the entire array for checking the value.
Either Linq or Conventional looping methods. Or you can use the
Array.Find()
also for the same. Better to go with the Linq and make the code is more simpler.
Happy coding
here is a function prints repeating int in a array.
in c#:
int [] ReturnDups(int[] a)
{
int repeats = 0;
Dictionary<int, bool> hash = new Dictionary<int>();
for(int i = 0; i < a.Length i++)
{
bool repeatSeen;
if (hash.TryGetValue(a[i], out repeatSeen))
{
if (!repeatSeen)
{
hash[a[i]] = true;
repeats ++;
}
}
else
{
hash[a[i]] = false;
}
}
int[] result = new int[repeats];
int current = 0;
if (repeats > 0)
{
foreach(KeyValuePair<int,bool> p in hash)
{
if(p.Value)
{
result[current++] = p.Key;
}
}
}
return result;
}
now converted to JAVA by Tangible software's tool.
in java:
private int[] ReturnDups(int[] a)
{
int repeats = 0;
java.util.HashMap<Integer, Boolean> hash = new java.util.HashMap<Integer>();
for (int i = 0; i < a.length i++)
{
boolean repeatSeen = false;
if (hash.containsKey(a[i]) ? (repeatSeen = hash.get(a[i])) == repeatSeen : false)
{
if (!repeatSeen)
{
hash.put(a[i], true);
repeats++;
}
}
else
{
hash.put(a[i], false);
}
}
int[] result = new int[repeats];
int current = 0;
if (repeats > 0)
{
for (java.util.Map.Entry<Integer,Boolean> p : hash.entrySet())
{
if (p.getValue())
{
result[current++] = p.getKey();
}
}
}
return result;
}
but findbug find this line of code as bugs. and it looks very odd to me too.
if (hash.containsKey(a[i]) ? (repeatSeen = hash.get(a[i])) == repeatSeen : false)
can someone pls explain to me what this line does and how do i write it in java properly?
thanks
You have overcomplicated the code for TryGetValue - this simple translation should work:
if ( hash.containsKey(a[i]) ) {
if (!hash.get(a[i])) {
hash.put(a[i], true);
}
} else {
hash.put(a[i], false);
}
C# has a way to get the value and a flag that tells you if the value has been found in a single call; Java does not have a similar API, because it lacks an ability to pass variables by reference.
Do not directly convert C# implementation. assign repeatSeen value only if the id is there.
if (hash.containsKey(a[i]))
{
repeatSeen = hash.get(a[i]).equals(repeatSeen)
if (!repeatSeen)
{
hash.put(a[i], true);
repeats++;
}
}
To answer the actual question that was asked:
if (hash.containsKey(a[i]) ? (repeatSeen = hash.get(a[i])) == repeatSeen : false)
is indeed syntactically wrong. I haven't looked at the rest of the code, but having written parsers/code-generators in my time I'm guessing it was supposed to be
if (hash.containsKey(a[i]) ? (repeatSeen = hash.get(a[i])) == repeatSeen) : false)
It's gratuitously ugly -- which often happens with code generators, especially ones without an optimizing pass -- but it's syntactically correct. Let's see if it actually does have a well-defined meaning.
CAVEAT: I haven't crosschecked this by running it -- if someone spots an error, please tell me!
First off, x?y:z is indeed a ternary operator, which Java inherited from C via C++. It's an if-then-else expression -- if x is true it has the value y, whereas if x is false it has the value z. So this one-liner means the same thing as:
boolean implied;
if (hash.containsKey(a[i]) then
implied = (repeatSeen = hash.get(a[i])) == repeatSeen);
else
implied = false;
if(implied)
... and so on.
Now, the remaining bit of ugliness is the second half of that and-expression. I don't know if you're familiar with the use of = (assignment) as an expression operator; its value as an operator is the same value being assigned to the variable. That's mostly intended to let you do things like a=b=0;, but it can also be used to set variables "in passing" in the middle of an expression. Hardcore C hackers do some very clever, and ugly, things with it (he says, being one)... and here's it's being used to get the value from the hashtable, assign it to repeatSeen, and then -- via the == -- test that same value against repeatSeen.
Now the question is, what order are the two arguments of == evaluated in? If the left side is evaluated first, the == must always be true because the assignment will occur before the right-hand side retrieves the value. If the right side is evaluated first, we'd be comparing the new value against the previous value, in an very non-obvious way.
Well, in fact, there's another StackOverflow entry which addresses that question:
What are the rules for evaluation order in Java?
According to that, the rule for Java is that the left argument of an operator is always evaluated before the right argument. So the first case applies, the == always returns true.
Rewriting our translation one more time to reflect that, it turns into
boolean implied;
if (hash.containsKey(a[i]) then
{
repeatSeen = hash.get(a[i]));
implied = true;
}
else
implied = false;
if(implied)
Which could be further rewritten as
if (hash.containsKey(a[i]) then
{
repeatSeen = hash.get(a[i]));
// and go on to do whatever else was in the body of the original if statement
"If that's what they meant, why didn't they just write it that way?" ... As I say, I've written code generators, and in many cases the easiest thing to do is just make sure all the fragments you're writing are individually correct for what they're trying to do and not worry about whether they at all resemble what a human would have written do do the same thing. In particular, it's tempting to generate code according to templates which allow for cases you may not actually use, rather than trying to recognize the simpler situation and generate code differently.
I'm guessing that the compiler was drawing in and translating bits of computation as it realized it needed them, and that this created the odd nesting as it started the if, then realized it needed a conditional assignment to repeatSeen, and for whatever reason tried to make that happen in the if's test rather than in its body. Believe me, I've seen worse kluging from code generators.
Is there a way a comparison in a string value can return a Boolean value. Example.
If (5 > 5000) would obviously return a false value. But what i wanted to do is have the "5 > 5000" return a false value.
Example.
string com = "5 > 10";
so is there a way to make this com variable return a false value as if it was a comparison between integers.
No built-in way but NCalc can help here
NCalc.Expression expr = new NCalc.Expression("5>10");
bool b = (bool)expr.Evaluate();
You can even use parameters
NCalc.Expression expr = new NCalc.Expression("a<b");
expr.EvaluateParameter += (name, args) =>
{
if (name == "a") args.Result = 5;
if (name == "b") args.Result = 10;
};
bool b = (bool)expr.Evaluate();
There is no built-in way to do this.
Although there are a couple of ways to approach this, one is to simply parse the text yourself. I did this in the code presented in the article A C# Expression Evaluator. You might want to review that code.
No, this can't be done directly.
You should write your own class or extend the String class. For handling a string such as "5 < 10", you need your own method.
You should search the string for signs that indicate comparison, such as "<", "==" etc, then split it and perform the comparison.
Basically: doing it yourself is the only way, but you can try to do it in an elegant way.
Short answer: no.
Long answer: feel free to parse the string yourself, looking for > < and =. Split by whitespace, parse ints then evaluate. It might get harder if you want it to work with parentheses as well...
Not directly, per se (short of the unsafe Javascript eval-execute-my-data hack) but you can try parsing it yourself, depending on how complicated of an expression you want to accept. For example, this should work with the string you have:
var arr = com.Split('>').Select(x=>int.Parse(x.Trim())).ToArray();
return arr[0] > arr[1];
You can also use regular expressions to get more complicated (untested, but it ought to work):
var r = new Regex(#"(\d+)\b*(<|>|=|<=|>=)\b*(\d+)")
var match = r.Match(com);
if(match.Success)
{
var a = int.Parse(match.Captures[0]);
var b = int.Parse(match.Captures[2]);
switch(match.Captures[1])
{
case "<":
return a < b;
case "=":
return a = b;
case ">":
return a > b;
case "<=":
return a <= b;
case "<=":
return a >= b;
}
}
//uh-oh
throw new ArgumentException("com");
Consider using FLEE:
Flee is an expression parser and evaluator for the .NET framework. It allows you to compute the value of string expressions such as sqrt(a^2 + b^2) at runtime. It uses a custom compiler, strongly-typed expression language, and lightweight codegen to compile expressions directly to IL. This means that expression evaluation is extremely fast and efficient. Try out the demo, which lets you generate images based on expressions, and see for yourself.
With FLEE you can easily accomplish this using something like:
var con = new ExpressionContext();
const string com = #"5 > 5000";
var comparison = con.CompileDynamic(com);
var result = comparison.Evaluate();
MessageBox.Show(result.ToString());
HTH...
I've implemented a TryParse function for a class MinMax like this:
public static bool TryParse(string s, out MinMax result)
{
var parts = s.Split(' ');
if (parts.Length != 2)
{
return false;
}
float min;
float max;
if (!float.TryParse(parts[0].Trim(), out min) || !float.TryParse(parts[1].Trim(), out max))
{
return false;
}
result = new MinMax(min, max);
return true;
}
However this doesn't compile since apparently the out parameter needs to be written. What's the correct way to fix this? I would like to be able to use the function so that if the parsing fails, the parameter passed into it remains unchanged. I guess one way would be to add something like:
result = result;
but this line issues a warning.
Pass by ref:
public static bool TryParse(string s, ref MinMax result)
which means you will have to ensure the result parameter is initialised.
Update: It is better to stick to the well known semantics of TryParse. (I'm sometimes critised for answering the real question not the one that was asked! On this occasion it was the opposite!)
Assuming MinMax is a reference type, just assign null to it. Just like any other TryParse method would work.
Check out this code:
string s = "12dfsq3";
int i = 444;
int.TryParse(s, out i);
Console.WriteLine(i);
i will be set to 0 instead of remaining at 444.
Given that an out parameter doesn't even need to be initialized by the caller, you really have to do something with it.
You could use a ref parameter instead, those don't require you to touch them in your function.
I don't like these answers telling you to use a ref parameter as it changes the semantics of the method and will require callers to pass an initialised value.
Set result to the default value for MinMax, which is null if it's a reference type, or use the default operator.
result = default(MinMax);
The only correct way to not update an out variable is to throw an exception. Change out to ref.
You have to set the value of the out variable. You could use ref as other answers have suggested, but I wouldn't recommend it - that's not how the standard TryParse pattern is supposed to work. Besides, it's ugly and unnecessary.
It doesn't really matter what result contains in the failure case, since the bool that you return indicates whether the parsing was successful or not. Just return new MinMax(0, 0) or, if you prefer, default(MinMax):
public static bool TryParse(string s, out MinMax result)
{
string[] parts = s.Split(' ');
if (parts.Length == 2)
{
float min, max;
if (float.TryParse(parts[0].Trim(), out min)
&& float.TryParse(parts[1].Trim(), out max))
{
result = new MinMax(min, max);
return true;
}
}
result = default(MinMax); // or just use "result = new MinMax(0, 0);"
return false;
}
I came across the following expression in someone else's code. I think it's terrible code for a number of reasons (not least because it fails to take into account bool.TrueString and bool.FalseString), but am curious as to how the compiler will evaluate it.
private bool GetBoolValue(string value)
{
return value != null ? value.ToUpper() == "ON" ? true : false : false;
}
Edit
Incidentally, aren't the expressions evaluated from the inside-outwards? In this case, what's the point of checking for value != null after the call to value.ToUpper() which will throw a null reference exception?
I think the following is a correct (deliberately) verbose version (I'd never leave it like this :D ):
if (value != null)
{
if (value.ToUpper() == "ON")
{
return true;
}
else // this else is actually pointless
{
return false;
}
}
else
{
return false;
}
Which can be shortened to:
return value != null && value.ToUpper == "ON";
Is this a correct re-writing of the expression?
It looks like the method is indended to handle a value that comes from a checkbox HTML element. If no value is specified for the checkbox, it uses the value "on" by default. If the checkbox is not checked there is no value at all from it in the form data, so reading the key from Request.Form gives a null reference.
In this context the method is correct, althought it's quite horrible due to the use of the if-condition-then-true-else-false anti-pattern. Also it should have been given a name that is more fitting for it's specific use, like GetCheckboxValue.
Your rewrite of the method is correct and sound. As the value is not culture dependant, converting the value to uppercase should not use the current culture. So a rewrite that is even slightly better than the one that you proposed would be:
return value != null && value.ToUpperInvariant == "ON";
(The culture independent methods are also a bit faster than the ones using a specific culture, so there is no reason not to use them.)
Incidentally, aren't the expressions
evaluated from the inside-outwards?
If it was method calls so that all expressions were actually evaluated, they would, as the inner call has to be made to evaluate the parameters for the outer call.
However, the second and third operands of the conditional expression is only evaluated if they are used, so the expressions are evaluated from the outside and inwards. The outermost condition is evaluated first to decide which of the operands it will evaluate.
You are correct, both in your rewriting and in your assertion that this attempt at conciseness is bad because it leads to confusion.
well the first one is a double-nested ternary operator
return (value != null) ? [[[value.ToUpper() == "ON" ? true : false]]] : false;
The bit in [[[ ]]] is the first result of the ternary expression which gets evaluated
when the first condition is true so you're reading/assertion of it is correct
but its ugly as hell and very unreadable/unmaintainable in its current state.
I'd definitely change it to your last suggestion
SideNote:
People who do
if(X == true)
return true;
else
return false;
instead of
return X;
should be taken out and shot ;-)
Are you looking for speed or readability and organization? Speed of execution, your shortened example is probably the best way to go.
For a few extra milliseconds, you could re-write this utility method as an extension method like so:
public static bool ToBoolean(this string value)
{
// Exit now if no value is set
if (string.IsNullOrEmpty(value)) return false;
switch (value.ToUpperInvariant())
{
case "ON":
case "TRUE":
return true;
}
return false;
}
... and then you would use it as follows:
public static void TestMethod()
{
bool s = "Test".ToBoolean();
}
EDIT:
Actually, I'm wrong... a quick performance test shows that the extension method is FASTER than the inline method. The source of my test is below, as well as the output on my PC.
[Test]
public void Perf()
{
var testValues = new string[] {"true", "On", "test", "FaLsE", "Bogus", ""};
var rdm = new Random();
int RunCount = 100000;
bool b;
string s;
Stopwatch sw = Stopwatch.StartNew();
for (var i=0; i<RunCount; i++)
{
s = testValues[rdm.Next(0, testValues.Length - 1)];
b = s.ToBoolean();
}
Console.Out.WriteLine("Method 1: {0}ms", sw.ElapsedMilliseconds);
sw = Stopwatch.StartNew();
for (var i = 0; i < RunCount; i++)
{
s = testValues[rdm.Next(0, testValues.Length - 1)];
b = s != null ? s.ToUpperInvariant() == "ON" ? true : s.ToUpperInvariant() == "TRUE" ? true : false : false;
}
Console.Out.WriteLine("Method 2: {0}ms", sw.ElapsedMilliseconds);
}
Output:
Method 1: 21ms
Method 2: 30ms
I read the original expression the same way you do. So I think your shortened expression is correct. If value is null it will never get to the second conditional, so it looks safe to me.
I also hate the constructs like:
if (value.ToUpper() == "ON")
{
return true;
}
else // this else is actually pointless
{
return false;
}
as you noticed it is a long and convoluted (not to say stupid) way of writing:
return value.ToUpper() == "ON";
Your proposition is nice, short and correct.
Another alternative:
return string.Equals( value, "ON", StringComparison.OrdinalIgnoreCase );