I guess that the list, hash and tree manipulation functions are more interesting in this case. A bit more of information: for the inlining to be successful, the inlined function and the function that calls it must be in the same file scope. What is usually done is to declare and define the function in a header, so every file that includes it has a copy of the function. Since the function is declared static as well, it will not be exported outside this scope, so no conflicting simbols will be found when the linker comes into action. The gcc option to assure that a function will be inlined is -finline-functions, and there should be an equivalent option for Microsoft compiler as well.
As can be seen in the gcc manual (http://developer.apple.com/documentation/developertools/gcc-3.3/gcc/Optimize-Options.html), the compiler still has the final word on which function will be inlined (look for the -finline-functions switch), so simple functions have high probability to be inlined. From my experience, recursive functions wont be inlined. On Mon, Nov 24, 2008 at 3:18 PM, Supun Kamburugamuva <[EMAIL PROTECTED]> wrote: > I also tried to find the C99 compatibility of Microsoft compilers. But the > details are not that clear. Yes, inline functions can increase the > performance. But we should consider the overhead work and complexity vs > performance. If we are going to introduce inline functions, one ideal place > will be for getter/setter functions. > > Thanks, > Supun. > > On Mon, Nov 24, 2008 at 8:31 PM, Thiago Rafael Becker > <[EMAIL PROTECTED]> wrote: >> >> I'm a unix guy, and in this platform, the portability is good for c99 >> (but gcc doesn't implement it completely, as you can see in [1]). >> Looks like Microsoft compilers are compatible with this startdard, if >> they implement full compatibility with C++/TR1 specification - and >> looks like the /TP implements this compatibility. But I can't find >> anything clear on this issue, and I could find some pointers to some >> failures on microsoft compilers[2]. Extra pointers in [3]. >> >> [1] http://gcc.gnu.org/c99status.html >> [2] >> http://coding.derkeiler.com/Archive/C_CPP/comp.lang.c/2007-03/msg05350.html >> [3] http://www.dinkumware.com/tr1.aspx, >> >> http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/913a2001-d2a6-450a-a15e-ff97ab6da0f1/ >> >> Responding to Supun, static inline functions can increase the size of >> binaries a bit, but there's no hit in performance. And some functions, >> if inlined, can improve the overall performance. It works more or less >> like macros, but with type verification at compile time and correct >> debugging pointers. Both type verification and correct debugging >> pointers can be cited as advantages of c99 over ansi c. >> >> >> Thanks. >> >> On Sat, Nov 22, 2008 at 3:26 AM, Damitha Kumarage <[EMAIL PROTECTED]> >> wrote: >> > Thiago Rafael Becker wrote: >> >> >> >> Hi, all >> >> >> >> I was looking at the recursive functions and below are my findings. >> >> >> >> In the case of axis2_core_utils_internal_build_rest_map_recursively, >> >> which is a tail-recursive function, seems easy to convert it to a >> >> iterative function. >> >> >> >> In the case of >> >> axis2_core_utils_internal_infer_op_from_rest_map_recursively, >> >> which is not a tail-recursive function, seems harder to do. Also, it >> >> spans for about 250 lines, it's complicated to find how to convert it. >> >> Did you ever thought about switching from ansi c to iso99 c? You can >> >> do some things to reduce the line span of functions (static inline >> >> functions) that you can't do with ansi c. What do you think about it? >> >> >> > >> > How about portability if we adopt C99? >> > thanks >> > Damitha >> > >> > -- >> > __________________________________________________________________ >> > >> > Damitha Kumarage >> > http://people.apache.org/ >> > __________________________________________________________________ >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> >> -- >> Thiago Rafael Becker >> http://www.monstros.org/trbecker >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > -- > Software Engineer, WSO2 Inc > http://wso2.org > Web Services with Axis2/C http://wsaxc.blospot.com > > -- Thiago Rafael Becker http://www.monstros.org/trbecker --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
