<div dir="ltr"><div>ohh, you are right, thank you!<br><br></div><div>If all node's pointers are NULL, the node isn't in the heap, but there is one special case for root node, this node doesn't point to another one.<br><br>I already fixed it in the function. Thank you again.<br><br>Diogo</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-31 3:02 GMT-03:00 Henning Rogge <span dir="ltr"><<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">No,<br>
<br>
I think we are mostly fine...<br>
<br>
Just a last question about the new "heap_is_node_added" inline... are<br>
you sure about the second return command? I think it will only return<br>
"true" if all three fields in the heap are NULL.<br>
<br>
What are you trying to test, are ALL of these fields initialized<br>
normally or just a few of them?<br>
<br>
If all of them are !NULL I would suggest replacing the if() condition<br>
and the both return with:<br>
> return node && node->parent && node->left && node->right;<br>
<br>
if just one of them should be !NULL, maybe this will work:<br>
> return node && (node->parent || node->left || node->right);<br>
<br>
Henning<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Jul 31, 2015 at 7:55 AM, Diogo Gonçalves<br>
<<a href="mailto:diogomachadogoncalves@gmail.com">diogomachadogoncalves@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> I updated my binary heap lib in the olsrd [1] with some static functions. Is<br>
> there something else that I can do?<br>
><br>
> [1]<a href="https://github.com/diogomg/olsrd" rel="noreferrer" target="_blank">https://github.com/diogomg/olsrd</a><br>
><br>
> 2015-07-30 9:22 GMT-03:00 Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>>:<br>
>><br>
>> Hi,<br>
>><br>
>> I lost a bit track of this while away at the IETF in Prague...<br>
>><br>
>> Can you send a new patch with the current version of the code to the<br>
>> list? I think we can clean up the rest inside the <a href="http://olsr.org" rel="noreferrer" target="_blank">olsr.org</a> repository.<br>
>><br>
>> Is the github code still "up to date" in terms of the head.[ch] code?<br>
>> If yes I will give it a try to use it in the olsrd2 Dijkstra too.<br>
>><br>
>> Henning Rogge<br>
>><br>
>> On Tue, Jul 14, 2015 at 9:27 PM, Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>> wrote:<br>
>> > Yes,<br>
>> ><br>
>> > that looks better... always a good idea to keep the internal functions<br>
>> > hidden.<br>
>> ><br>
>> > Henning<br>
>> ><br>
>> > On Tue, Jul 14, 2015 at 5:19 PM, Diogo Gonçalves<br>
>> > <<a href="mailto:diogomachadogoncalves@gmail.com">diogomachadogoncalves@gmail.com</a>> wrote:<br>
>> >> HI,<br>
>> >><br>
>> >> I cleaned up my heap.h[1], leaving only functions for the users, as you<br>
>> >> asked me. I hope i'm on right way but I know that there are<br>
>> >> improvements to<br>
>> >> do, so if you have something else to suggest you can ask me.<br>
>> >><br>
>> >><br>
>> >> [1] <a href="https://github.com/diogomg/olsrd" rel="noreferrer" target="_blank">https://github.com/diogomg/olsrd</a><br>
>> >><br>
>> >> 2015-07-13 14:10 GMT-03:00 Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>>:<br>
>> >>><br>
>> >>> Hi,<br>
>> >>><br>
>> >>> since we have some people to ask when we have questions about it, I<br>
>> >>> think it will be good to merge.<br>
>> >>><br>
>> >>> But I would also like someone of you to look after it when I build it<br>
>> >>> into the olsrd2 dijkstra. If you can clean up the "heap.h" file so<br>
>> >>> that it only contains the necessary functions for an user (and not the<br>
>> >>> internal ones), it should be easy to supply a few good accessor macros<br>
>> >>> (similar to list.h and avl.h in OONF).<br>
>> >>><br>
>> >>> Henning<br>
>> >>><br>
>> >>> On Mon, Jul 13, 2015 at 7:07 PM, Saulo Queiroz <<a href="mailto:ssaulojorge@gmail.com">ssaulojorge@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>> > Ferry and Henning,  ok.<br>
>> >>> > We have just to care about real routing metrics, like ETX<br>
>> >>> > since the priority queue will be arranged based on such<br>
>> >>> > real value. What you think?<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > On 13 July 2015 at 13:47, Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>> wrote:<br>
>> >>> >><br>
>> >>> >> On Mon, Jul 13, 2015 at 6:01 PM, Saulo Queiroz<br>
>> >>> >> <<a href="mailto:ssaulojorge@gmail.com">ssaulojorge@gmail.com</a>><br>
>> >>> >> wrote:<br>
>> >>> >> > Yes,<br>
>> >>> >> > something like 1/priority_value (for instance) might work.<br>
>> >>> >><br>
>> >>> >> I thought more about (UINT32_MAX-value)<br>
>> >>> >><br>
>> >>> >> Henning<br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > --<br>
>> >>> > Saulo Jorge bq<br>
>> >>> > -<br>
>> >>> > "In theory, there is no difference between practice and theory, in<br>
>> >>> > practice<br>
>> >>> > there is"<br>
>> >>> > -- Someone<br>
>> >><br>
>> >><br>
><br>
><br>
</div></div></blockquote></div><br></div>