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. -- 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
