This is partly because an AtomicInteger is not a general purpose replacement for an Integer. The java.util.concurrent.atomic package summary states: Atomic classes are not general purpose replacements for java.lang.Integer and related classes. They do not define methods such as hashCode and compareTo. (Because atomic variables are expected to be mutated, they are poor choices for … Read more
String s = “”; String s2 = someUserInputVariale.toLowercase(); // where the user entered in “” Something like that would cause s == s2 to evaluate to false. Lots of code sill create new Strings without exposing the call to new String().
Apache commons-collections has CollectionUtils#isEqualCollection: Returns true if the given Collections contain exactly the same elements with exactly the same cardinality. That is, if the cardinality of e in a is equal to the cardinality of e in b, for each element e in a or b. Which is, I think, exactly what you’re after.
This is generally (i.e., always) a bad idea. As you suspected, the comparison from 3 to 3.0000001 will indeed fail. What most people do, if an int-float comparison is really necessary, is pick some threshold of tolerance and go with that, like so: int x = 3; float y = 3.0; // some code here … Read more
There are several things going on. Firstly, in this example: string s1 = “a”; string s2 = “a”; Console.WriteLine(s1 == s2); You claim that: Both are different object reference. That’s not true due to string interning. s1 and s2 are references to the same object. The C# specification guarantees that – from section 2.4.4.5 of … Read more
In general, it’s not at all safe to compare the hashCode instead of using equals. When equals returns false, hashCode may return the same value, per the contract of hashCode.
in Eclipse right mouse click-> source -> generate hashCode() and equals() gives this: /* (non-Javadoc) * @see java.lang.Object#hashCode() */ @Override public int hashCode() { final int prime = 31; int result = 1; result = prime * result + (code == null ? 0 : code.hashCode()); return result; } /* (non-Javadoc) * @see java.lang.Object#equals(java.lang.Object) */ … Read more
Implementing IEquatable<T> for a Value Type Implementing IEquatable<T> for a value type is a little bit different than for a reference type. Let’s assume we have the Implement-Your-Own-Value-Type archetype, a Complex number struct. public struct Complex { public double RealPart { get; set; } public double ImaginaryPart { get; set; } } Our first step … Read more
How does that work if the fields that it’s based on are mutable? It doesn’t in the sense that the hash code will change as the object changes. That is a problem for all of the reasons listed in the articles you read. Unfortunately this is the type of problem that typically only show up … Read more
Nice question, the surprising thing about the code above is that println “${‘test’}”.equals(‘test’) returns false. The other line of code returns the expected result, so let’s forget about that. Summary “${‘test’}”.equals(‘test’) The object that equals is called on is of type GStringImpl whereas ‘test’ is of type String, so they are not considered equal. But … Read more