Hi,

Le 26.07.2013 01:54, Carsten Haitzler a écrit :
> 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).
> >>
> >
> > 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 ;)


> --
> ------------- Codito, ergo sum - "I code, therefore I am" 
> --------------
> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
> 
> 
> ------------------------------------------------------------------------------
> 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

-- 
Raoul Hecky

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

Reply via email to