=== robbiew is now known as robbiew-afk [05:07] Keybuk: thought: nih_discard should run the destructor always. [09:39] sadmac: why? [14:17] Keybuk: Think of it in the case of our most common destructor: removing the node from a list. Discard should only leave the item around for people still referencing it, which means external references like that should go away. === robbiew-afk is now known as robbiew [14:37] right, but that's not how it's supposed to work ;-) [14:37] discard is "drop the NULL reference" [14:38] the assumption is that you allocate an object with a NULL reference, pass it to something that actually references it [14:38] and then drop the NULL ref [14:38] if it didn't get referenced, dropping the NULL ref does free it [14:38] e.g. [14:38] void *foo; [14:38] foo = nih_new (NULL, SomeObject); [14:39] nih_list_init (&foo->entry); [14:39] pass_to_some_func (foo); [14:39] nih_discard (foo); [14:39] ... [14:39] where [14:39] pass_to_some_func (void *foo) [14:39] { [14:39] nih_list_add (&foos, &foo->entry); [14:39] nih_ref (foo, &foos); [14:39] } [14:41] well that's what it /does/ sure :) The name to me implies "normal operation of the program is done with this object. Only keep it around if something hasn't remembered to dereference it yet." [14:42] In a more literal sense, "discarding" the object should take it out of a list. [14:42] it's more equivalent to g_ref_sink in the old libgtk style referencing [14:44] Keybuk: also I've occasionally found a list that I'd prefer used internal referencing (i.e. actually do nih_ref (list, list->next) etc rather than just having a destructor pull it out when its done). I was thinking of adding a second set of list helpers to facilitate maintaining a list in this way. [14:45] sure, that's more like how nih_list_entry works, no? [14:45] hm? [14:45] * sadmac2 pulls a libnih tree onto his work machine [14:47] NihList is embedded in structures [14:47] NihListEntry is an NihList with a generic pointer [14:47] where the list references the data contained in it [14:48] oic. that's an interesting way of doing it... [14:48] does its destructor unreference its target pointer then? [14:48] you could make it do that [14:50] then you could just use nih_free on the entry to remove from the list [14:50] in theory the list/alloc stuff should be flexible enough to do it either way [14:51] one of my other two libnih-using projects doesn't use the embedded list stuff [14:51] because every object is in multiple lists [14:52] I've also had some ideas I'm sitting on about how to reduce nih_alloc's overhead and possibly make it a bit more flexible, but I'm still churning. [14:56] I have a thought that we could kill the parent/child lists and store a big adjacency matrix instead within a good sparse matrix data structure [14:57] might perform better too (cache lines hate linked lists) === robbiew is now known as robbiew-afk === robbiew-afk is now known as robbiew === notting_ is now known as notting