On Fri, 26 Jul 2013 11:26:47 +0200 Raoul Hecky <raoul.he...@gmail.com> said:
> 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 ;)
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.
>
> > --
> > ------------- 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
--
------------- 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
