On Fri, 26 Jul 2013 12:57:24 +0100 Tom Hacohen <tom.haco...@samsung.com> said:
> On 26/07/13 11:23, Carsten Haitzler (The Rasterman) wrote:
> > 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.
>
> 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.
--
------------- 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
