On 26/07/13 15:33, Carsten Haitzler (The Rasterman) wrote: > On Fri, 26 Jul 2013 12:57:24 +0100 Tom Hacohen <[email protected]> said: > >> On 26/07/13 11:23, Carsten Haitzler (The Rasterman) wrote: >>> On Fri, 26 Jul 2013 11:26:47 +0200 Raoul Hecky <[email protected]> said: >>> >>>> Hi, >>>> >>>> Le 26.07.2013 01:54, Carsten Haitzler a écrit : >>>>> 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.) >>>> >>>> >>>> I did not follow the entire eo/eo2 discussion, but here are some >>>> comments on the "eo_filter" >>>> thing. >>>> Qt uses a similar tool called moc which is a preprocessor (Meta Object >>>> Processor) that >>>> takes care of handling Qt's C++ extensions (It takes a c++ files and >>>> search for the Q_OBJECT >>>> macro in class definitions and creates a new c++ file containing the >>>> meta-object code for >>>> those classes). It let Qt add a lot of different meta programing thing >>>> that is not >>>> directly available with C++ through the use of specific qt keywords. >>>> There is a proof of concept for a rewrite of the moc tool using clang >>>> directly to enhance >>>> the code parsing and error reporting with all the Qt'ish keywords >>>> (slot/signals/...) >>>> http://woboq.com/blog/moc-with-clang.html >>>> >>>> Maybe something similar for eo could be a good solution instead of >>>> having a lot of >>>> unreadable macros that will always display incomprehensible errors when >>>> not used >>>> correctly. >>>> Having an external preprocessor tool can allow to do thing that are not >>>> possible using >>>> standard C, and most importantly it can report any wrong usage of eo >>>> correctly and >>>> display usefull error messages. >>>> >>>> My 2 cents here ;) >>> >>> i'm with you. a moc-style preprocessor would cut out a tonne of ugliness and >>> arguments and boilerplate fluff. it could warn/error on all the things that >>> are wrong AND be portable as all it has to do is read a file, parse and >>> output the same text post-parse/expand. >>> >>> problem is a bunch of people are just dead set against it arguing it >>> "creates a new language" "it's not c anymore", etc. etc. and thus we must >>> not do it. i personally think these arguments to be academic and purist in >>> nature and ultimately just cost us work and pain for nothing but an >>> academic argument. >> >> To be honest, as the biggest objector, I must admit, I'm starting to >> agree it might not be that bad of an idea. >> >> However, I do think that even if we have that, we still need good C API >> (we'll have to generate C code anyway), so it's a bit of a futuristic >> thing, or at least something that has little to do with the topic at hand. > > no disagreement on this. we shouldnt make an awful c api and just assume a > preprocessor will fix it up. we should make the best "raw c" thing we can, but > some things are just a tiny bit beyond the reach of normal c without a little > pre-processing. >
Yes. I agree. Let me rephrase my original email: Hey zealots, get away from my thread with your preprocessing trolling. :) -- Tom. ------------------------------------------------------------------------------ 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
