Hash table code question

This is a discussion on Hash table code question within the C Programming forums, part of the General Programming Boards category; Hi,
I'm having difficulty understanding part of a hash table code example from my textbook. I don't understand why the ...

Hash table code question

Hi,

I'm having difficulty understanding part of a hash table code example from my textbook. I don't understand why the pointer to a pointer to an Element "ptrUpdate" is strictly necessary when the pointer to an Element "ptrCurr" transverses the linked list of Elements in exactly the same way as ptrUpdate except for one less level of indirection.

My best current guess is that, since this example is supposed to be part of a case study on aspects of Instruction Level Parallelism and run-time hardware scheduling, the apparent redundancy is really just for exposing additional instruction level parallelism in the loops, or at least smoothing it out.

I don't trust that guess, which is why I'm asking you (it has been awhile since I coded in C).

Is there absolutely no way to store element[i] to the original object through ptrCurr? Like, say, *ptrCurr = element[i] ?

That would be assinging struct to struct which isn't allowed in C. But you don't want to copy elements, you want to update their pointers (->next), so you must use pointer to pointer to modify pointer "in-place".

I believe that is technically not specified, but in the implementations I've seen it either calls memcpy() or implements the same functionality inline for larger structures. Small structures may be copied with simpler constructions, but generally copying all bytes of the struct in 32-bit chunks. What difference does it make? You can't "use" those padding bytes for anything, so whether they are copied or not wouldn't make much meaningful difference.

I believe that is technically not specified, but in the implementations I've seen it either calls memcpy() or implements the same functionality inline for larger structures. Small structures may be copied with simpler constructions, but generally copying all bytes of the struct in 32-bit chunks. What difference does it make? You can't "use" those padding bytes for anything, so whether they are copied or not wouldn't make much meaningful difference.

--
Mats

When you do data/integrity checking and have CRC32 of whole struct, it could make difference...

When you do data/integrity checking and have CRC32 of whole struct, it could make difference...

Yes, I suppose so. But then I would try to ensure that I knew where and how much the padding was too - by adding my own filler bytes and then verifying that sizeof(mystruct) == expected size somewhere in the early stages of the code. That way, there would be no "surprise holes".

Edit: Seeing as you probably need the CRC checks because the data passes from one application to another [probably via some network or similar], you would have to know that the size matches at both ends some way or another.

But I think you can ALMOST 100&#37; trust the compiler to copy the entire struct, padding included.