On Sat, 29 Oct 2011, Cedric BAIL wrote:
> On Fri, Oct 28, 2011 at 4:45 PM, Vincent Torri <vto...@univ-evry.fr> wrote: >> On Fri, 28 Oct 2011, Cedric BAIL wrote: >>> On Fri, Oct 28, 2011 at 2:13 PM, Youness Alaoui >>> <kakar...@kakaroto.homelinux.net> wrote: >>>> I agree with vincent, and I think that there shouldn't be a "define it >>>> before including eina.h" implicit rule.. while it's not so bad, and it >>>> would >>>> work, it's not the right way to do it. >>>> these functions shouldn't be inlined I think, they should be a define, and >>> >>> Using define instead of inline has a lot issue. First it doesn't let >>> the compiler when it's better or not to inline, it will always inline. >>> Second it doesn't do any type checking so you can break stuff much >>> more easily. And generally inline is much more easy to read than >>> define. >>> >>>> for the posix functions, they are way too big to be inline, they would >>>> dramatically increase the generated code, especially if you lock/unlock >>>> everywhere. >>> >>> I actually don't understand what point your are trying to make here. >>> >>>> As for performance, give us hard numbers! I don't think it would >>>> affect performance for such function calls. So in my opinion, make them >>>> defines, and have the posix versions as actual functions that the defines >>>> call (so for non posix with smaller functions, you don't need an actual >>>> call). >>> >>> What does matter is call to small function, because the overhead of >>> setting up the stack, saving register, jumping to the actual function >>> to call and then coming by restoring register and the stack does >>> introduce a cost. Something you will not see on your high end laptop, >>> but on embedded device. And the inline function are function that are >>> typically in the hot path of our stack, so function call really do >>> matter. And moving to #define would not solve the issue Vincent is >>> pointing as far as I understand it. >> >> indeed. So, with the argument of Jorge, there are 2 problems. > > No, there is no such problem. The compiler flag will not change any > behaviour in eina library or I really missed something and please show > me example code. And as for giving header random order support I > really don't think it's important and worth it. did you read my mail about the example with raster's habit of putting everything in a private header ? I mean, really read it ? You didn't give any answer to it... Vincent > It's just good > practice to respect dependencies and don't rely on the hope that > something magic will happen. > -- > Cedric BAIL > > ------------------------------------------------------------------------------ > Get your Android app more play: Bring it to the BlackBerry PlayBook > in minutes. BlackBerry App World™ now supports Android™ Apps > for the BlackBerry® PlayBook™. Discover just how easy and simple > it is! http://p.sf.net/sfu/android-dev2dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
