Occurs to me Go language calls this "deferred", in it we could defer a call to be called at every exit point.
Maybe there is an defer extension to compilers providing deferred calls in c? --Gustavo Sent from my iPhone On 25/07/2013, at 20:54, Carsten Haitzler (The Rasterman) <[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). >>> >>> Already showed you a solution, the one with the bla function. It works >>> and it's mostly clean. >> >> >> how so? The __VA_ARGS__ may contain a return and it will never reach >> eo2_do_end() > > precisely. current eo just can't do it (compiler will barf). if we could make > the compiler barf... that'd be great! this doesn't work, but if it could: > > #define eo2_do(obj_id, ...) \ > do { \ > obj_ptr_or_ctx = eo2_do_start(obj_id); \ > if(!obj_ptr_or_ctx) break; \ > do { \ > #define return DONT_USE_RETURN_HERE \ > #define goto DONT_USE_GOTO_HERE \ > __VA_ARGS__ ; \ > #undef return \ > #undef goto \ > } while (0); \ > eo2_do_end(obj_ptr_or_ctx); \ > } while (0) > > then this would be awesome. even if it only worked for gcc (and maybe clang) > as > extensions, i'd be happy enough. some way to disallow it. > > right now, the only thing that comes to mind is the evil "preprocessor before > cpp". i.e. : > eo_filter file.c | gcc - -o file.o > vs > gcc file.c -o file.o > > and eo_filter is a tool we have to make that can error out and detect things > like the above... (bonus... it can do other fun things too that cpp/c can't > and > expand code etc.) > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > ------------------------------------------------------------------------------ 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
