[PD] Updated pd-extended

[Billy Stiltner]

i'm clueless

On Fri, Sep 26, 2014 at 11:40 AM, Jonathan Wilkes via Pd-list <
pd-list at 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 <
> zmoelnig at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140927/fa3e0ae6/attachment.html>