On Sat, Jul 27, 2013 at 11:47 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Sat, 27 Jul 2013 22:54:07 +0200 Jérémy Zurcher <jer...@asynk.ch> said:
>
>> On Saturday 27 July 2013 11:10, Carsten Haitzler wrote :
>> > On Fri, 26 Jul 2013 14:57:28 -0300 Lucas De Marchi
>> > <lucas.demar...@profusion.mobi> said:
>> >
>> > > On Thu, Jul 25, 2013 at 8:54 PM, Carsten Haitzler <ras...@rasterman.com>
>> > > wrote:
>> > > > On Thu, 25 Jul 2013 14:58:30 -0300 Gustavo Sverzut Barbieri
>> > > > <barbi...@profusion.mobi> said:
>> > > >
>> > > >> On Thu, Jul 25, 2013 at 1:46 PM, Tom Hacohen <tom.haco...@samsung.com>
>> > > >> wrote:
>> > > >> > On 24/07/13 03:09, Carsten Haitzler (The Rasterman) wrote:
>> > > >> >> On Tue, 23 Jul 2013 18:22:02 +0200 Jérémy Zurcher <jer...@asynk.ch>
>> > > >> >> said:
>> > > >> >>
>> > > >> >>> just to clarify a few points:
>> > > >> >>>
>> > > >> >>> - I think the less macro we have in an eo class declaration the
>> > > >> >>> best, actually we have nothing but that extra first parameter
>> > > >> >>> called eo2_o, wich is either an obj_ptr (devs/tasn/eo2) or a
>> > > >> >>> call_ctx (devs/jeyzu/eo2)
>> > > >> >>>
>> > > >> >>> this should go away if we use a stack per thread in eo private
>> > > >> >>> code, so we end up with a clean
>> > > >> >>> EAPI float times(float f, float t);
>> > > >> >>>
>> > > >> >>> - since day 1 break is supported in eo2_do:
>> > > >> >>> #define eo2_do(obj_id, ...)
>> > > >> >>> do
>> > > >> >>> {
>> > > >> >>> obj_ptr_or_ctx = eo2_do_start(obj_id);
>> > > >> >>> if(!obj_ptr_or_ctx) break;
>> > > >> >>> do { __VA_ARGS__ ; } while (0);
>> > > >> >>> eo2_do_end(obj_ptr_or_ctx);
>> > > >> >>> } while (0)
>> > > >> >>
>> > > >> >> i'm worried about people doing return there. seriously - objid came
>> > > >> >> in becau se of experience that people using efl are in general
>> > > >> >> inexperienced programmers who don't take the time to do things
>> > > >> >> right. they do things quickly and take shortcuts, and they ignore
>> > > >> >> warnings. they'd rather patch out abort()s in efl code forcing them
>> > > >> >> to fix their bugs, than fix their bugs. i am fearful that they will
>> > > >> >> stuff in returns quite happily and think it mostly works most of
>> > > >> >> the time... and then find subtle issues and waste our time finding
>> > > >> >> them.
>> > > >> >>
>> > > >> >> how do we protect/stop returns (or goto's for that matter) within
>> > > >> >> the while block. i looked for some pragmas - can't find any to do
>> > > >> >> this. this would be a really useful compiler feature though (to
>> > > >> >> maybe disable some constructs for a sequence of code).
>> > >
>> > > What you seem to be looking for is the cleanup attribute.
>> > >
>> > > #define eo2_do(obj_id, ...)
>> > > do
>> > > {
>> > > obj_ptr_or_ctx = eo2_do_start(obj_id);
>> > > if(!obj_ptr_or_ctx) break;
>> > > do
>> > > {
>> > > obj_ptr_or_ctx_type __attribute__((cleanup(eo2_do_end))
>> > > dummy = obj_ptr_or_ctx;
>> > > __VA_ARGS__ ;
>> > > } while (0);
>> > > } while (0);
>> > >
>> > >
>> > > But then we need to take a look if the cleanup function will run when
>> > > the actual function returns, or when the second "do" runs out of
>> > > scope. This attribute is more commonly used to call free on the
>> > > variable, so it doesn't matter much.... but for us this would make a
>> > > difference if it involves locking.
>> > >
>> > > Then you just allow break and return, and the right thing will happen,
>> > > even in those cases.
>> >
>> > voila! that would do it (if it does work on return as well as break and any
>> > goto that jumps out of the while scope). if course it'd be dependant on
>> > compiler supporting it - if it doesnt, then we cleanup by hand as normal on
>> > a break and return/goto just create bugs. i'd be ok with that. need to add
>> > -fexceptions maybe too from a quick read. needs a little experimenting and
>> > some method of detection. looks like its single parameter only and i guess
>> > it is done variable by variable which is good enough for us. :) i wonder
>> > how new it is. hmm looks like gcc 3.3 - that means it's rather old by now.
>> > GOOD. i hope clang supports it too and.... it seems not. :( oh well. let's
>> > hope most devs still use gcc. :)
>> >
>>
>> nice one,
>> implemented and tested with gcc 4.8.1 and clang 3.3
>>
>> http://git.enlightenment.org/core/efl.git/commit/?h=devs/tasn/eo2&id=275280c3e0fb74e01ffd682acfb69f6a2700dc40
>
> one problem - no compiler feature detection - if compiler doesnt support it
If the compiler doesn't support it, it will basically fail to compile
once the macro expands. If you want to support both compilers that
support and those which don't.... good luck ;-)
GCC and clang support this, IMO others should catch up.
Lucas De Marchi
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
