i'm clueless On Fri, Sep 26, 2014 at 11:40 AM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
> Now I'm even more confused. In the past you had written this to a query > of mine: > > >On 01/12/2013 12:04 AM, Jonathan Wilkes wrote: > >>>>> In C would I just make a struct with fields of t_symbol, > >>>>> > >>>>> t_class, and a pointer to link to the next one? > >>>> > >>>> > >>>> Yeah, a linked list would work fine, probably not as efficient as >the > >>>> c++ hash structure (but lots easier > >to maintain). One nit-to-pick: Use a t_class pointer, which is a >t_pd. > >> > >> > >> Hm... since the code to add new classes to the list will probably > >> end up looking exactly like the code to add symbols to the > >> symbol table, what if I just bloat the _symbol struct by adding > >> a t_class *s_class? Would that affect performance? > > >it would break binary compatibility. > > But now you say the opposite in response to DesireData's _symbol struct which > adds a refcount and a symbol size member "n". > > How does the one break binary compatibility but the other does not? > > -Jonathan > > > > On Friday, September 26, 2014 1:48 AM, IOhannes m zmölnig < > zmoel...@iem.at> wrote: > > > 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. > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list