On Sat, Oct 29, 2011 at 8:08 PM, Vincent Torri <vto...@univ-evry.fr> wrote: > 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...
Yes, I did. And I still don't konw how to answer it, because I just agree with your point. I agree that's a bad habit, that it should be fixed and that your fix were right. And I think every one did as in so many year nobody reverted them. So I have nothing to argue with you about your argument at all, but you still see that as a bug, despite your argument. So I really don't know what to say or argue, as I just agree with your point. -- 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
