Function pointers

[clibs]

Function pointers

[tj]

the .free field doesn't actually have anything to do with free() itself, just happens to be the name of that field, but the reason for it is so that you can assign the function that should be called to clean up all the node values, instead of iterating/freeing them all manually. There's no function to assign or anything though, just like this https://github.com/visionmedia/list/blob/master/test.c#L130. Likewise here's an example .match https://github.com/visionmedia/list/blob/master/test.c#L130 so you can filter values by some custom function

[humanshell]

OMG! I totally get it. They're NULL 'stubs' or 'placeholders'.

It dawned on me that looking at your test.c could provide some insight to how those fields were intended to be used. I was starting to understand when your reply came in and that just confirmed it. It's actually REALLY cool, providing an empty 'plug' where a consumer of your library or api can insert their own custom function to handle cleanup and comparisons. Very nice.

It just leaves me with two questions about the list_find() and list_remove() functions:

1.) both the list_remove() and list_destroy() functions call the .free field, but they're not the same. destroy calls self->free(curr->val) and remove calls self->free(node). Is there a reason these calls differ? The former passes the current node's value while the latter passes the node itself. I'm thinking that remove is just a singular form of destroy, shouldn't these two methods pass similar arguments to the .free field?

2.) list_find() is the only function using the .match field. I'm confused by the conditional fallback. If no function has been attached to the .match field, then a simple '==' comparison is performed on the passed in val and the current node's val. Won't this comparison always fail because it's comparing pointer values? The passed in val points to one thing and the current node's val points to something else. While the data in memory may be the "same" won't those pointer addresses always be different, causing the comparison to always return false?

[jonathanmarvens]

Closing this issue as solved (given it wasn't an issue anyway).