On Monday 29 July 2013 10:31, Lucas De Marchi wrote :
> On Sat, Jul 27, 2013 at 5:54 PM, Jérémy Zurcher <jer...@asynk.ch> wrote:
> > 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
>
> Humn... taking what you committed:
>
> // eo object method calls batch,
> // DO NOT use return statement in it, use break if necessary
> #define eo2_do(objid, ...) \
> do \
> { \
> - Eo *_objid_ = objid; \
> + Eo *_objid_ EO2_DO_CLEANUP = objid; \
> if (!eo2_do_start(_objid_, EINA_FALSE)) break; \
> - do { __VA_ARGS__ ; } while (0); \
> - eo2_do_end(); \
> + __VA_ARGS__; \
>
> you still need to stuff the __VA_ARGS__ into a do { } while (0).
> Otherwise you are calling eo2_do_end() when eo2_do_start() failed.
thanks a lot, I forgot about that !
as cleanup is related to variable scope, __VA_ARGS__ is not part of the story,
just move _objid_ down to fix, checked with clang and gcc
http://git.enlightenment.org/core/efl.git/commit/?h=devs/tasn/eo2&id=a4818d13150114ed0909014c658996be07cf272a
>
>
>
> >
> > but has Tom pointed to me that on Windows you can't use an EAPI func ptr
> > to init a struct, what about this cleanup attribute ?
>
> humn? the cleanup function is called with a pointer to the variable
> when we go out of scope. That's it... it's basically the compiler
> injecting code for us. If the compiler on windows has support for
> this attribute, I can't see how it would not support it being an EAPI
> function (not function ptr).
>
> 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
--- Hell'O from Yverdoom
Jérémy (jeyzu)
------------------------------------------------------------------------------
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
