On 09/26/2014 04:22 AM, Jonathan Wilkes via Pd-list wrote:
On 09/25/2014 12:54 PM, Jonathan Wilkes via Pd-list wrote:
Um... have you actually read the source for DesireData?
Just to clarify this-- from m_pd.h desiredata 2010.01.05:
struct _symbol { char *name; /* the const string that represents this symbol */ t_pd *thing; /* pointer to the target of a receive-symbol or to the bindlist of several targets */ struct _symbol *next; /* brochette of all symbols (only for permanent symbols) */ size_t refcount; /* refcount<0 means that the symbol is permanent */ size_t n; /* size of name (support for NUL characters) */ #ifdef PD_PLUSPLUS_FACE bool operator == (const char *s) const {return strcmp(this->name,s)==0;} bool operator != (const char *s) const {return strcmp(this->name,s);} #endif };
Desiredata's t_symbol has extra members that aren't in Pd Vanilla's t_symbol struct. If there is any external out there that uses an array of symbols, then there will be problems due to this binary compatibility.
actually, i have yet to come across a *single* external that uses (t_symbol) rather than (t_symbol*) - or, if you insist on arrays (t_symbol[]) rather than (t_symbol*[]).
i don't see how this breaks binary compatibility - unless of course you *use* these members¹...
fmgdsr IOhannes
¹ that is, pass them around, in a "dosomething(s->foo)" sort of way (and i don't know how to do this with an overloaded operator). since the additional members are actually methods with an implementation in the header file, i guess that any compiler would just inline them when it comes to using them (in an "s->foo(z)" sort of way), rather than forcing a resolving via dynamic lookup.