On Sat, Apr 30, 2011 at 5:59 PM, Gustavo Sverzut Barbieri < [email protected]> wrote:
> On Fri, Apr 29, 2011 at 3:54 PM, Enlightenment SVN > <[email protected]> wrote: > > Log: > > Eina refcount: Wrap EINA_REFCOUNT_UNREF with do {} while(0). > > #define EINA_REFCOUNT_UNREF(Variable, Free_Callback) \ > > - if (--((Variable)->__refcount) == 0) \ > > - Free_Callback(Variable); > > + do \ > > + { \ > > + if (--((Variable)->__refcount) == 0) \ > > + Free_Callback(Variable); \ > > + } \ > > + while (0) > > maybe think of a way to set Free_Callback automatically? Spread this > all around the code will be bad? > I don't really agree. If the free callback is type specific then you'll get a compilation warning when doing something wrong and how different is it from just calling our custom unref_my_special_item? I.e it's EINA_REFCOUNT_UNREF(item, free_my_item); v.s unref_my_item(item); Both are error-prone the same way. Coming to think about it, the current way is not good because it breaks inheritance. Here's an example of something that will break: struct parent { EINA_REFCOUNT; int foo; }; struct child { struct parent p; int bar; }; there's no sane way to do struct child item; ... EINA_REFCOUNT_UNREF(item, free_my_item); because child->__refcount doesn't exist and passing &child->parent instead will cause a compilation warning when calling free_my_item... I guess we should drop this refcount thingie, too much hassle and issues. -- Tom. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
