On Fri, 6 Dec 2013 17:26:21 -0200 Gustavo Sverzut Barbieri <barbi...@gmail.com>
said:
> On Fri, Dec 6, 2013 at 10:42 AM, David Seikel <onef...@gmail.com> wrote:
> > On Fri, 6 Dec 2013 10:12:09 -0200 Gustavo Sverzut Barbieri
> > <barbi...@gmail.com> wrote:
> >
> >> On Thu, Dec 5, 2013 at 10:23 PM, Daniel Juyung Seo
> >> <seojuyu...@gmail.com> wrote:
> >> > Dear all, this is Daniel Juyung Seo.
> >> >
> >> > I propose EFL_SAFE_FREE macro for efl.
> >> > It looks like:
> >> >
> >> > # define EFL_SAFE_FREE(_h, _fn) do { if (_h) { _fn((void*)_h); _h
> >> > = NULL; } } while (0)
> >> >
> >> > As I have been using ELM_SAFE_FREE for months, I found out that
> >> > this macro is quite useful in terms of code readability, reducing
> >> > human mistakes, and using much smaller number of lines with the
> >> > same functionality.
> >> >
> >> > Enlightenment has
> >> > # define E_FREE_FUNC(_h, _fn) do { if (_h) { _fn((void*)_h); _h =
> >> > NULL; } } while (0)
> >> >
> >> > Elementary has
> >> > #define ELM_SAFE_FREE(_h, _fn) do { if (_h) { _fn((void*)_h); _h =
> >> > NULL; } } while (0)
> >> >
> >> > So why not efl?
> >> >
> >> > By using EFL_SAFE_FREE, this (Old) code will reborn as a (New) code.
> >> > 5 lines down to 1 line.
> >> > (Old)
> >> > if (svr->until_deletion)
> >> > {
> >> > ecore_timer_del(svr->until_deletion);
> >> > svr->until_deletion = NULL;
> >> > }
> >> >
> >> > (New)
> >> > EFL_SAFE_FREE(svr->until_deletion, ecore_timer_del);
> >>
> >> bad name as there is nothing save in it.
> >>
> >> EINA_FREE_AND_NULL(ptr, freefunc) would be more descriptive, code is
> >> the same. Or:
> >>
> >> EINA_FREE_AND_NULL(ptr) // does free()
> >> EINA_DISPOSE_AND_NULL(ptr, disposefunc) // generic version
> >>
> >> I'm not a native speaker, eventually there is a better name for the
> >> second one.
> >
> > Safe, as in "this is the safe way to do it", nothing to do with saving
> > things.
>
> i know, but what is safe in it? Because it checks for null before
the "safe" here is that it makes things safe afterwards. you no longer have a
dangling pointer variable (in case you use it again now you've freed the
object).
> calling the function? If you take libc "free()" this is not required,
> so it's no big deal. The set to NULL is also something not always
> desired, if you're cleaning up a local variable all tools
> (gcc/clang/coverity) will report dead assignment. Tools won't report
> but it's also not needed (or desired) if you clean a member of a
> struct that is also being deleted.
>
>
> --
> Gustavo Sverzut Barbieri
> --------------------------------------
> Mobile: +55 (19) 9225-2202
> Contact: http://www.gustavobarbieri.com.br/contact
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
