[snip]
Also, there are declarations after functional lines, e.g.,
- change_bindlist_via_graph = 1; t_bindelem *e;
which is not standard C - something I frequently have to clean up in
people's
patches :)
You mean declaration of a global variable needs to be placed at the top of the source file? Sure, that is an easy fix. It's been placed here in proximity to make the patch more legible.
It's an automatic variable whose declaration should be at the beginning of a block. Otherwise Visual C++ seems to get offended (and I don't find out until I crank up my stupid windows machine :)
But it is declared as a global variable at the beginning of the diff so it is not an automatic variable that is destroyed after function exits:
+static int change_bindlist_via_graph = 0;
+static void bindlist_cleanup(t_bindlist *x)
Are you saying that I need to re-declare it within the function? If so, that is the first time I would've seen anything like it and it is something certainly the rest of the Pd code does not conform to, either (or at least pd-extended).
I'm just saying that the automatic varable t_bindelem *e should be declared at the beginning of the block - no worries about change_bindlist_via_graph.
I think something like what you proposed could work; there would still be
a
performance hit which I'd probably want to measure before committing to doing this... since after all we're just talking about a wierd and
obnoxious
'feature' in IEMGUIs that I would simply take out if I could :)
I am not so sure there is a performance hit since in both cases dereferencing happens in exactly the same way, except in this one the referencing is delayed and in the interim structs destined to be dereferenced are made to point to null and then skipped if a subsequent call trips over a null-pointing struct before it has been dereferenced. As such its performance impact should be minimal.
Main performance hit would be that every time anyone traverses a bindlist (many send/receive messages, perhaps most) there's all that extra code in bindlist_bang(), etc. needed to make the extra tests (possible zero receiver and possible cleanup needed afterward).
Clean-up afterward is already implemented and is done within bindlist_cleanup() call which is nearly identical in terms of its workload to what was originally placed within pd_unbind, so I seriously doubt this will make much if any difference.
What will potentially add a bit of an overhead is the call above that I forgot to add:
if (e->e_who != NULL) pd_whatever(e->e_who);
I honestly have no idea how much a single if statement checking for a null pointer requires in terms of CPU usage. That said, FWIW I seriously doubt that this one if would cause that much of cpu overhead even if executed on a large number of calls.
I think bindlist_bang() etc are more critical than pd_unbind as they naturally get called many times while a patch is running whereas pd_unbind is typically called only when objects are deleted. So moving checks from pd_unbind() to bindlist_bang() etc decreases pd's run-time efficiency.
cheers M