On 30/06/15 03:14, Carsten Haitzler wrote:
> On Mon, 29 Jun 2015 17:34:26 +0100 Tom Hacohen <t...@osg.samsung.com> said:
>
>> On 29/06/15 17:21, Cedric BAIL wrote:
>>> On Mon, Jun 29, 2015 at 5:50 PM, Tom Hacohen <t...@osg.samsung.com> wrote:
>>>> On 29/06/15 15:53, Cedric BAIL wrote:
>>>>> On Mon, Jun 29, 2015 at 4:18 PM, Tom Hacohen <t...@osg.samsung.com> wrote:
>>>>>> On 29/06/15 14:32, Cedric BAIL wrote:
>>>>>>> I think that eo_do_ret and eo_do_super_ret are quite hugly to use and
>>>>>>> unecessary. I think they should be gone. Their behavior can still be
>>>>>>> nice to have especially inside efl tree. The reason they exist is that
>>>>>>> we want to support other compiler than GCC and Clang for application
>>>>>>> that use EFL. EFL itself can not be compiled by anything else than GCC
>>>>>>> and Clang.
>>>>>>> Maybe we should provide #if piece of code that will enable the old
>>>>>>> non portable behavior of eo_do and eo_do_super for people who are sure
>>>>>>> that there code should not be running on something else than GCC and
>>>>>>> Clang. So if someone want the current behavior of eo_do_ret and
>>>>>>> eo_do_super_ret, but in a nice way, he will just do a #define EFL_GNU
>>>>>>> (or whatever we decide) before including Eo.h.
>>>>>>>
>>>>>>> As we are heading to stabilize Eo API in EFL 1.15, I really would
>>>>>>> prefer to get rid of this _ret variant.
>>>>>>
>>>>>> I don't see why this "ret" variant is a problem. We could keep it there,
>>>>>
>>>>> It is a very confusing one. You have to pass the variable you want it
>>>>> to return stuff in. Once you are at the point of needing a variable,
>>>>> well, ... why do you still need to use eo_do_ret ? Basically useless.
>>>>
>>>> It's not useless, it's good for things like:
>>>> if (eo_do_ret(...))
>>>> but mostly for things like:
>>>> if (something)
>>>> else if (eo_do_ret(...))
>>>>
>>>> or
>>>> if (something && eo_do_ret(...))
>>>
>>> You are missing a point here, you always have a useless variable
>>> anyway in the parameter. So something like :
>>>
>>> if (something)
>>> {
>>> int bob;
>>>
>>> if (eo_do_ret(... bob ...))
>>>
>>> Or something like that. Sure you can add this variable at the top of
>>> your function, but that doesn't reduce how disturbing it is. Why do I
>>> need a variable ? What does it do ? (That's rethorical question, but
>>> having to read useless piece of code is lowering the quality of the
>>> code by creating confusion.
>>>
>>
>> I'm not missing the point. I've made my point. The purpose of the
>> variable is to work around standard c limitations. We could also get
>> around them with gnu extensions. I gave a few examples where it's useful.
>
> i'm going to go back to my hated proposal... we add a better CPP in front of
> CPP. use ecc instead of gcc or clang etc. (and ecc will parse/process and
> generate new c code that then is passed to $CC - much like ccache or distcc).
>
> this will solve all such problems. :)
I'm not going to be the one writing this...
--
Tom.
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
