On Fri, Oct 28, 2011 at 4:45 PM, Vincent Torri <[email protected]> wrote: > On Fri, 28 Oct 2011, Cedric BAIL wrote: >> On Fri, Oct 28, 2011 at 2:13 PM, Youness Alaoui >> <[email protected]> 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. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
