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 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