On Tue, Jun 30, 2015 at 3:14 AM, Carsten Haitzler <ras...@rasterman.com> 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).

We can't do that.. if we did I wouldn't be able to mock qt for having moc.

>
> this will solve all such problems. :)
>
>> >>>> there's no problem with that. It's useful for people want to write
>> >>>> portable code. For the different eo_do behaviour, we could have a define
>> >>>> that changes eo_do to the non portable version if we think it's really
>> >>>> needed. I don't really like the idea, but I don't object. Just offering
>> >>>> a better way of doing it. :)
>> >>>
>> >>> I fail to see the difference with my proposal, but if you are fine
>> >>> with it, then go.
>> >>>
>> >>
>> >> I'm not fine and not not fine. I wanna see what people say. At the
>> >> moment, Daniel objects, you are in favour and I'm neutral.
>> >
>> > Daniel objects to everything. I didn't answer is mail as there is no
>> > argument in it. Objecting with no argument is clearly useless to a
>> > discussion.
>> >
>>
>>
>> --
>> Tom.
>>
>> ------------------------------------------------------------------------------
>> Monitor 25 network devices or servers for free with OpManager!
>> OpManager is web-based network management software that monitors
>> network devices and physical & virtual servers, alerts via email & sms
>> for fault. Monitor 25 devices for free with no restriction. Download now
>> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
>> _______________________________________________
>> 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
>
>
> ------------------------------------------------------------------------------
> 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

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

Reply via email to