-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlD0Bz0ACgkQkX2Xpv6ydvT0ggCg0h1nqbsPzsuKTUhxa+yd4Khk 9G4An1nt6vfPlQj3lMLf4+M0j9PJbk5F =J5Ry -----END PGP SIGNATURE----- _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
