-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-01-13 18:50, Jonathan Wilkes wrote:
but adding/revising code inside class_new would retain 100% binary compatibility, whereas adding members to public structures is a 100% guarantee to break binary compatibiliy.
And if I just put the struct inside m_class.c but not in m_pd.h is that enough to keep it from being "exposed"?
yes, that shouldn't be a problem. i was mainly concerned about your plans to extend the existing t_symbol (but i might have misunderstood your suggestion).
Another questions-- inside class_new when I add a class/symbol pair to the list (I suppose by calling a function to add an entry to the list), I need to walk the current list to see if that symbol has already been added and overwrite the old class pointer with the new one, right? And if so, won't this searching add to the patch load time?
yes. obviously, all code that you add will eventually take some ime to execute. however, i wouldn't worry too much about that before it becomes obvious that it takes too long...Pd already handles quite a number of linked lists that are searched linearily. e.g. calling class_new() already checks, whether the new class is already in the long list of objectclasses registered with pd_objectmaker, and this is not the reason why it takes long to load large patches.
otoh, it would of course be nice to abstract these hashtable-like structures away, in something like std::map; this would make it easy to switch to a different algorithm (eg. binary trees) once we find that a linear search is the bottleneck.
fgasmdr IOhannes