On Sat, Jul 27, 2013 at 5:54 PM, Jérémy Zurcher <[email protected]> wrote:
> On Saturday 27 July 2013 11:10, Carsten Haitzler wrote :
>> On Fri, 26 Jul 2013 14:57:28 -0300 Lucas De Marchi
>> <[email protected]> said:
>>
>> > On Thu, Jul 25, 2013 at 8:54 PM, Carsten Haitzler <[email protected]>
>> > wrote:
>> > > On Thu, 25 Jul 2013 14:58:30 -0300 Gustavo Sverzut Barbieri
>> > > <[email protected]> said:
>> > >
>> > >> On Thu, Jul 25, 2013 at 1:46 PM, Tom Hacohen <[email protected]>
>> > >> 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 <[email protected]>
>> > >> >> 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.
>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
