> There's nothing wrong with using an arbitrary field to break ties as long as the
> value of that field is stable. The order of equal elements is ultimately irrelevant,
> so any stable ordering solution is as good as any other.
What I meant is that (unless I'm misunderstanding his code), he's temporarily stuffing curcode into m_bits (which is not being used yet) so that he can get at it to use as a tie breaker inside the qsort compare...
m_huffnode[curcode].m_bits = curcode;
Then he later sets m_bits back to 0 after the sort...
node.m_bits = 0;
Essentially, he's hijacking an existing member of the node object and storing something else in it temporarily, which is fine, but it just seems like something that could be confusing if it wasn't documented clearly. That's why I suggested that there might be another way to do it that didn't involve hijacking m_bits. Unfortunately, I can't think of one.
At the points where m_bits is being set and later cleared aren't right before and after the sort, so unless you already understand what's going on, I don't think it would make much sense. And if you look inside the comparison function, it appears that m_bits is being compared between the two nodes, but actually the curcode for each node is being compared, it's just stored in m_bits.
GroovyMAME support forum on BYOAC
|
Previous 
Index 
Next 
Flat 
Re: bug: chdman output depends on system qsort() implementation
Reply
Re: bug: chdman output depends on system qsort() implementation
