<div dir="ltr">i'm clueless<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 11:40 AM, Jonathan Wilkes via Pd-list <span dir="ltr"><<a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><span>Now I'm even more confused.  In the past you had written this to a query of mine:</span></div><pre>>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.<br><br>But now you say the opposite in response to DesireData's _symbol struct which adds a refcount and a symbol size member "n".<br><br>How does the one break binary compatibility but the other does not?<span class="HOEnZb"><font color="#888888"><br><br>-Jonathan<br></font></span></pre> <div><br><br></div><div style="display:block"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div class="h5"> <div dir="ltr"> <font face="Arial"> On Friday, September 26, 2014 1:48 AM, IOhannes m zmölnig <<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>> wrote:<br> </font> </div>  <br><br> </div></div><div><div><div class="h5">On 09/26/2014 04:22 AM, Jonathan Wilkes via Pd-list wrote:<br>> On 09/25/2014 12:54 PM, Jonathan Wilkes via Pd-list wrote:<br>>> Um... have you actually read the source for DesireData?<br>> <br>> Just to clarify this-- from m_pd.h desiredata 2010.01.05:<br>> <br>> struct _symbol {<br>>     char *name;           /* the const string that represents this<br>> symbol */<br>>     t_pd *thing;          /* pointer to the target of a receive-symbol<br>> or to the bindlist of several targets */<br>>     struct _symbol *next; /* brochette of all symbols (only for<br>> permanent symbols) */<br>>     size_t refcount;      /* refcount<0 means that
 the symbol is<br>> permanent */<br>>     size_t n;             /* size of name (support for NUL characters) */<br>> #ifdef PD_PLUSPLUS_FACE<br>>     bool operator == (const char *s) const {return<br>> strcmp(this->name,s)==0;}<br>>     bool operator != (const char *s) const {return strcmp(this->name,s);}<br>> #endif<br>> };<br>> <br>> Desiredata's t_symbol has extra members that aren't in Pd Vanilla's<br>> t_symbol struct.  If there is any external out there that uses an array<br>> of symbols, then there will be problems due to this binary compatibility.<br>> <br><br>actually, i
 have yet to come across a *single* external that uses<br>(t_symbol) rather than (t_symbol*) - or, if you insist on arrays<br>(t_symbol[]) rather than (t_symbol*[]).<br><br>i don't see how this breaks binary compatibility - unless of course you<br>*use* these members¹...<br><br>fmgdsr<br>IOhannes<br><br><br>¹ that is, pass them around, in a "dosomething(s->foo)" sort of way (and<br>i don't know how to do this with an overloaded operator).<br>since the additional members are actually methods with an implementation<br>in the header file, i guess that any compiler would just inline them<br>when it comes to using them (in an "s->foo(z)" sort of way), rather than<br>forcing a resolving via dynamic lookup.<br><br><br><br></div></div><span class="">_______________________________________________<br><a>Pd-list@lists.iem.at</a> mailing list<br>UNSUBSCRIBE and account-management -> <a>http://lists.puredata.info/listinfo/pd-list</a><br><br><br></span></div>  </div> </div>  </div> </div></div><br>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div>