Win a copy of Microservices Testing (Live Project) this week in the Spring forum!

Eugene Wee

Greenhorn
+ Follow
since Dec 17, 2007
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Eugene Wee

Could there be practical use cases where you may want to override only hashCode() & not equals() ?


I do not think so. The Java 5 API states for hashCode:

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.



Consider:


Suppose we have two Derived objects d1 and d2. d1.x and d2.x are both 0, but d1.y is 1 are d2.y is 2. So, d1.equals(d2) is true, but d1.hashCode() is 1 and d2.hashCode() is 2. Therefore, even though the objects are equal according to the equals(Object) method, calling the hashCode method on each of them produces a different integer result. This breaks the hashCode contract.

[ May 13, 2008: Message edited by: Eugene Wee ]
[ May 13, 2008: Message edited by: Eugene Wee ]
14 years ago

Glad to have given a good explanation, but I was obviously mistaken about C and C++. Sorry


No problem, you did force me to look it up further than online FAQs, and this in turn led me to check more carefully your link.

So I take it that my citation of the Java Language Specification to justify my statement is sound?
14 years ago
The NIST Dictionary of Algorithms and Data Structures defines a balanced tree as: A tree where no leaf is much farther away from the root than any other leaf. Different balancing schemes allow different definitions of "much farther" and different amounts of work to keep them balanced.

In other words, a balanced tree is guaranteed not to degenerate into a linked list. As such, a search will take time proportional to the height of the tree (effectively O(log n)) instead of proportional to the number of elements (O(n)).
[ May 09, 2008: Message edited by: Eugene Wee ]
14 years ago
If B2 may have many elements, then it may be best to sort B2, and then iterate over B1, using binary search to find an element in B2 that is equal to the current element in B1. If such an element is found, remove the current element in B1.

On the other hand, if B1 may have many elements but B2 has only a few elements, then you could do the above, but sort B1 instead and iterate over B2.

If both B1 and B2 will have only a few elements, then you could iterate over B2 and use B1's remove() method that takes an Object with the current element in B2.
[ May 09, 2008: Message edited by: Eugene Wee ]
14 years ago
Recently, a user on a C and C++ forum community that I am part of asked a question concerning the result of:


Now, in C and C++, the above code has undefined behaviour. For some reason, another user mentioned Java, and yet another user claimed that the behaviour was also undefined in Java. I disagreed and asserted that in Java, the precise evaluation order is defined.

Unfortunately, I could not remember where I read that about Java, so I decided to search to confirm what I asserted. In particular, I found out that this topic by Shivit Agarwal came up last month: Order of Evaluation.

Campbell Ritchie's explanation of the order of execution seems pretty clear. On the other hand, it sounds like it is based simply on the precedence of the operators and their associativity: but C and C++ have the same relative precedence of prefix and postfix operator++, and the same associativity.

Campbell Ritchie also stated: "And the value of i++ + ++i; is defined in C and C++ to be exactly the same as in Java. There are some compilers available which are written incorrectly."

This claim this incorrect, since the C Standard (1999 edition) states in section 6.5:

Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.



The C++ Standard (2003 edition) states in section 5:

Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified. Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored.



After a little reading of the link to Chapter 15, The Java Language Specification, Third Edition provided by Campbell Ritchie, I found that it states in chapter 15.7:

The Java programming language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.



Is this then what makes the difference, and thus answers Shivit Agarwal's question and justifies my assertion?
14 years ago