81–90 of 104 posts
(Insert my usual rant about not checking malloc()/calloc() for failure.)
edit: clarity.
Earlier quoted context omitted.
With two additional casts you can make it compile[1] as C++ - without the incredibly wasteful extra local variable. [1] http://codepad.org/
Your link to " http://codepad.org/" doesn't show any code. Did you forget some arguments in the URL?
Is this some common style? int (**hnew()) I've never seen parens used like that. Usually it's: int **hnew()
[] has higher precedence than *, so without the parens you get "function returning array of two pointer to pointer to int" (which is illegal) instead of the desired "function returning pointer to pointer to array of two int".
typedef int arr2int[2];
typedef arr2int** ptr_arr2int;
#define SIZE 1024
static ptr_arr2int hnew() {
return calloc(sizeof(int**), SIZE);
}What's with the hardcoded size though...
target_row_number = table_height % int_value_of_key
If table height keeps changing then this formula would be inconsistent. This code isn't using % but kind of doing the same using &
Replace (int)[2] with table_row :)
I can see two legitimate cases for writing very short, very dense code. 1: Implement an algorithm in a very concise and straightforward, even if not very efficient, way. An example is the classic quicksort in Haskell, which most literally implements the idea of the algorithm: qsort [] = [] qsort (p:xs) = qsort [ y | y = p ] 2: Implement an algorithm in a super-efficient, while non-obvious, way. An example is the inve…
Also, even in examples of super efficient ways, be wary. The inverse square root you are referring to is actually slower than what many CPUs can do with a single instruction nowdays.
Also, I think you are missing out on the main reason this code was written. Essentially a puzzle to see if it can be done.
(Insert my usual rant about not checking malloc()/calloc() for failure.)
Is learning how to create a hash table necessary for a software engineer?
There's no bounds testing in hget(): some valid sequences of operations will cause buffer overflows. For example, this should segfault: int (**table)[2] = hnew(); for (int j=0; j The problem is, the probing function doesn't wrap (the "t += h" part), so if you have have several colliding keys, it will probe for them past the end of the table.
Every time a lookup is performed, isn't it linearly looking through the table to find that key... That doesn't sound like a hash! Maybe am missing something here.
h = k & (SIZE - 1)