On 12/07/2013 04:56 PM, Daniel Juyung Seo wrote:
> On Sat, Dec 7, 2013 at 11:27 PM, Gustavo Sverzut Barbieri <
> barbi...@gmail.com> wrote:
>
>> On Fri, Dec 6, 2013 at 10:19 PM, Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>>> 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
> Hello
>
>
>>> 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).
>>
> Yes. Exactly that is what this macro intended.
> As we discussed the same thing, ELM_SAFE_FREE,  long ago in the mailing
> list, "safe" looks good to me.
>
>
>> I've mentioned this over an over, while in some places we do want to
>> NULL the pointer because it is a valid value indicating something (ie:
>> no timer running, no object in use...) many others we do NOT want to
>> zero this pointer because the pointer shouldn't be used at all... and
>> if we stick a NULL and then check for such special value elsewhere
>> we're hiding bugs.
>>
>>
> Sure exactly. I already know that you mentioned this long before in the
> mailing list.
> As I mentioned in the first mail,this macro is not a silver bullet and
> should not be overused.
> So use it only when you have to.
>
> And about your suggestion about EINA_FREE_AND_NULL, having this macro in
> eina looks good.
> How do others think?
>
> EINA_SAFE_FREE!
ok for me. ELM_SAFE_FREE is very useful and it could be good to have the 
same for efl. The name seems good too imo.
>
>
>
>> Also, if you set a pointer to NULL you lose valgrind tracing. If you
>> do not set to NULL you can get it to say that the pointer was freed
>> elsewhere and then you can easily trace why your bug happened.
>>
>>
>>
> Yes I also remember you mentioned this before in the mailing list.
> So we should use this macro only when we really need it.
>
> If there is no objection I will work on EINA_SAFE_FREE.
>
> Thanks.
>
> Daniel Juyung Seo (SeoZ)
>
>
>
>> --
>> 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
>>
> ------------------------------------------------------------------------------
> 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
>


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

Reply via email to