C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  inline functions Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ language (comp.lang.c++) View previous topic :: View next topic   Author Message Rubén Campos Guest Posted: Thu Sep 16, 2004 10:08 am    Post subject: inline functions I haven't found any previous message related to what I'm going to ask here, but accept my anticipated excuses if I'm wrong. I want to ask about the real usefulness of the 'inline' keyword. I've read many authors (and it's my belief, too) who discourage the use of the 'inline' keyword, because: - The 'inline' word only advice the compiler about wich functions should be expanded, but not force it to expand them. Also, the compiler can decide to expand a function not declared as 'inline' by the programmer. So, in last instance, 'inline' function expansion it's completely guided by compiler's decisions, not by programmer's ones. - It is required to include 'inline' function definitions in the corresponding header file, with the consequences (recompilation of all source file including the target header file) that a change in them implies, specially in big projects. I'm sure about this, and I not use the 'inline' keyword. But recently I've seen opposed examples in some libraries' header files, "boost" between them. This fact have induced me to ask myself another time about this matter. Thank you :-) Back to top John Harrison Guest Posted: Thu Sep 16, 2004 10:30 am    Post subject: Re: inline functions "Rubén Campos" <Ruben.Campos (AT) robotica (DOT) uv.es> wrote Quote: I haven't found any previous message related to what I'm going to ask here, but accept my anticipated excuses if I'm wrong. I want to ask about the real usefulness of the 'inline' keyword. I've read many authors (and it's my belief, too) who discourage the use of the 'inline' keyword, because: - The 'inline' word only advice the compiler about wich functions should be expanded, but not force it to expand them. Also, the compiler can decide to expand a function not declared as 'inline' by the programmer. So, in last instance, 'inline' function expansion it's completely guided by compiler's decisions, not by programmer's ones. Not true. The compiler cannot inline a function that is in a different translation unit (assuming it does seperate compilation, which AFAIK they all do). So if you want to give the compiler the *opportunity* to inline a function in more than one translation unit it must go in a header file, and therefore it must be declared inline. Quote: - It is required to include 'inline' function definitions in the corresponding header file, with the consequences (recompilation of all source file including the target header file) that a change in them implies, specially in big projects. True enough, but you pay your money and you take your choice. Quote: I'm sure about this, and I not use the 'inline' keyword. But recently I've seen opposed examples in some libraries' header files, "boost" between them. This fact have induced me to ask myself another time about this matter. Thank you :-) john Back to top Ioannis Vranos Guest Posted: Thu Sep 16, 2004 10:56 am    Post subject: Re: inline functions Rubén Campos wrote: Quote: I haven't found any previous message related to what I'm going to ask here, but accept my anticipated excuses if I'm wrong. I want to ask about the real usefulness of the 'inline' keyword. I've read many authors (and it's my belief, too) who discourage the use of the 'inline' keyword, because: Not true. Inline is a useful feature for run-time optimisation, when used appropriately. Take a look at: http://www.research.att.com/~bs/esc99.html Quote: - The 'inline' word only advice the compiler about wich functions should be expanded, but not force it to expand them. Also, the compiler can decide to expand a function not declared as 'inline' by the programmer. So, in last instance, 'inline' function expansion it's completely guided by compiler's decisions, not by programmer's ones. However programmers may take more wise inlining decisions than the compiler. Also in most cases the compiler listens to the programmer inlining requests. Quote: - It is required to include 'inline' function definitions in the corresponding header file, with the consequences (recompilation of all source file including the target header file) that a change in them implies, specially in big projects. Inline should be used for small definitions, and in most such cases rarely the definition is changed slightly. Also if you want to avoid that, then do not inline. If you want the code to be inlined so as to avoid redundant function calls, while at the same time the produced binary will not get increased significantly if the specific function or member function is inlined, then use inline. There are not perfect solutions that resolve all problems, but the decisions are up to the programmer to take. Quote: I'm sure about this, and I not use the 'inline' keyword. But recently I've seen opposed examples in some libraries' header files, "boost" between them. This fact have induced me to ask myself another time about this matter. Thank you Of course. Inline is widely used and yields significant benefits when used appropriately. -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top E. Robert Tisdale Guest Posted: Thu Sep 16, 2004 5:19 pm    Post subject: Re: inline functions Rubén Campos wrote: Quote: I want to ask about the real usefulness of the 'inline' keyword. I think that you just did. Quote: I've read many authors (and it's my belief, too) who discourage the use of the 'inline' keyword, because: - The 'inline' word only advice the compiler about which functions should be expanded, but [does] not force it to expand them. Also, the compiler can decide to expand a function not declared as 'inline' by the programmer. So, in last instance, 'inline' function expansion [is] completely guided by compiler's decisions, not by [the] programmer's [decisions]. No, not quite. The compiler can't expand a function inline if the function definition is not visible to the compiler -- if the function definition is in a different translation unit for example. Quote: - 'inline' function definitions must be included in the corresponding header file, with the consequences that a change in them implies (recompilation of all source file including the target header file) especially in big projects. Yes. In general, you pay a penalty at compile time for optimizations that enhance performance at run time. Quote: I'm sure about this, and I [do] not use the 'inline' keyword. But, recently, I've seen opposed examples in some libraries' header files "boost" [among] them. This fact has induced me to ask myself another time about this matter. You need to ask yourself a question, "Do I really care about performance?" If you do, you will probably want to use as many inline function definitions as possible. You might consider taking advantage of both: Quote: cat file.h #ifndef GUARD_FILE_H #define GUARD_FILE_H 1 #ifdef EFINE_INLINE inline double f(double x) { return x*(x + 2.0) + 1.0; } #else //EFINE_INLINE double f(double x); #endif//EFINE_INLINE #endif//GUARD_FILE_H Quote: cat file.cc #undef EFINE_INLINE #include "file.h" double f(double x) { return x*(x + 2.0) + 1.0; } Quote: g++ -DEFINE_INLINE -Wall -ansi -pedantic -O3 -c file.cc nm --demangle file.o 00000000 T f(double) This allows your inline and external function definitions to coexist peacefully. Use the -DEFINE_INLINE option only after you have finished testing and debugging all of your code. This will speed up the program development cycle and allow you to optimize your code just before deployment. Back to top Rubén Campos Guest Posted: Fri Sep 17, 2004 9:40 am    Post subject: Re: inline functions Well, first of all thank you, John, Ioannis and Robert, for your answers. You're right when you talk about the need of having inline function declaration and definition both in the same translation unit. Related to the code model proposed by Robert, I think the next model I found in the book "Industrial C++" is better: // MyClass.h .... class MyClass { void MyInlineMethod (); }; .... #ifdef ENABLE_INLINE #include "MyClass.inl" #endif // #ifdef ENABLE_INLINE // MyClass.cpp #include "MyClass.h" .... #ifndef ENABLE_INLINE #include "MyClass.inl" #endif // #ifndef ENABLE_INLINE // MyClass.inl #ifndef ENABLE_INLINE #define inline #endif // #ifndef ENABLE_INLINE .... inline void MyClass::MyInlineMethod () { cout << "This is an inline member function" << endl; } .... #ifndef ENABLE_INLINE #undef inline #endif // #ifndef ENABLE_INLINE Again, inlining can be enabled or disabled by defining or not defining ENABLE_INLINE macro. The reasons for which I think it's better are: - MyClass header file does not include any function implementation. - Inline function implementation does not need to be duplicated. The only problem I see with this is the definition of a language keyword ("#define inline"). Perhaps it can be avoided by replacing 'inline' with a custom 'INLINE' macro, defined as 'inline' or as empty, depending if the ENABLE_INLINE is defined. Back to top Ioannis Vranos Guest Posted: Fri Sep 17, 2004 10:11 am    Post subject: Re: inline functions Rubén Campos wrote: Quote: Well, first of all thank you, John, Ioannis and Robert, for your answers. You're right when you talk about the need of having inline function declaration and definition both in the same translation unit. Related to the code model proposed by Robert, I think the next model I found in the book "Industrial C++" is better: // MyClass.h ... class MyClass { void MyInlineMethod (); }; ... #ifdef ENABLE_INLINE #include "MyClass.inl" #endif // #ifdef ENABLE_INLINE // MyClass.cpp #include "MyClass.h" ... #ifndef ENABLE_INLINE #include "MyClass.inl" #endif // #ifndef ENABLE_INLINE // MyClass.inl #ifndef ENABLE_INLINE #define inline #endif // #ifndef ENABLE_INLINE ... inline void MyClass::MyInlineMethod () { cout << "This is an inline member function" << endl; } ... #ifndef ENABLE_INLINE #undef inline #endif // #ifndef ENABLE_INLINE Again, inlining can be enabled or disabled by defining or not defining ENABLE_INLINE macro. The reasons for which I think it's better are: - MyClass header file does not include any function implementation. - Inline function implementation does not need to be duplicated. The only problem I see with this is the definition of a language keyword ("#define inline"). Perhaps it can be avoided by replacing 'inline' with a custom 'INLINE' macro, defined as 'inline' or as empty, depending if the ENABLE_INLINE is defined. Avoid macros as much as possible. In all decent compilers, if you need to disable inlining of inline functions and member functions, the compiler provides a special compiler switch. -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top E. Robert Tisdale Guest Posted: Fri Sep 17, 2004 8:25 pm    Post subject: Re: inline functions Ioannis Vranos wrote: Quote: Avoid macros as much as possible. In all decent compilers, if you need to disable inlining of inline functions and member functions, the compiler provides a special compiler switch. You missed the point. We don't want to disable inlining. We want to prevent the compiler from processing the inline function definitions because it takes time and slows down development cycles. We use the C preprocessor to remove the inline function definitions and substitute external function declarations in the translation unit so that the program will compile and link faster. Back to top Ioannis Vranos Guest Posted: Sat Sep 18, 2004 10:48 am    Post subject: Re: inline functions E. Robert Tisdale wrote: Quote: You missed the point. We don't want to disable inlining. We want to prevent the compiler from processing the inline function definitions because it takes time and slows down development cycles. We use the C preprocessor to remove the inline function definitions and substitute external function declarations in the translation unit so that the program will compile and link faster. I have not much development history, but don't all modern compilers support incremental compilation, so as to not recompile anything that has already been compiled? -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top Andy Guest Posted: Sat Sep 25, 2004 4:41 am    Post subject: Re: inline functions "E. Robert Tisdale" <E.Robert.Tisdale (AT) jpl (DOT) nasa.gov> wrote Quote: You need to ask yourself a question, "Do I really care about performance?" If you do, you will probably want to use as many inline function definitions as possible. That's a dangerous statement, Bob. One has to use 'inline' functions as judiciously as one can. 'inline'-ing is not evil, but used without enough thought or judgment, it can soon be the next worst thing for your program's performance in time and space. Scott Meyers writes an amazing item on this issue in Effective C++. For one, all calls to an inlined function will be replaced by the function's object code - object code replication - potentially leading to code bloat. Second, and this is very important, you got to consider the behaviour of your compiler when "inline" requests cannot be satisfied. How the compiler handles "outlined" inlines determines whether your code suffers any code-bloat. Never inline virtual functions because they would hardly ever be inlined. How can the compiler know which function to inline when it does not know at compile time which function to call. Also, using inline calls with debuggers is trouble-some. I guess, inlining should only be considered at the time of optimized builds, not the initial builds anyway. Modern day compilers are smart enough to ignore almost any inlining request that doesn't beggar a lookin for itself. Only the simplest and shortest functions manage to convince the compiler to inline them ... and that too needs the inline directive or being defined within the body of the class. Cheers, Andy Back to top E. Robert Tisdale Guest Posted: Sat Sep 25, 2004 5:32 am    Post subject: Re: inline functions Andy wrote: Quote: E. Robert Tisdale wrote: You need to ask yourself a question, "Do I really care about performance?" If you do, you will probably want to use as many inline function definitions as possible. That's a dangerous statement. One [must] use 'inline' functions as judiciously as one can. 'inline'-ing is not evil but, used without enough thought or judgment, it can soon be the next worst thing for your program's performance in time and space. Scott Meyers writes an amazing item on this issue in Effective C++. For one, all calls to an inlined function will be replaced by the function's object code - object code replication - potentially leading to code bloat. The typical application here at the Lab is about 2 MBytes. The typical processing node has 2 GBytes memory -- the application code absorbs about 0.1% of that. I can get disk space for about $0.50 per GByte at Fry's which means that it costs me about 0.1 cents to keep a "bloated" application program on my hard drive. Code bloat is *not* a problem -- for me or most other C++ programmers. Quote: Second, and this is very important, you [must] consider the behavior of your compiler when "inline" requests cannot be satisfied. How the compiler handles "outlined" inlines determines whether your code suffers any code-bloat. Never inline virtual functions because they would hardly ever be inlined. How can the compiler know which function to inline when it does not know at compile time which function to call. Also, using inline calls with debuggers is trouble-some. I guess, inlining should only be considered at the time of optimized builds, not the initial builds anyway. Modern day compilers are smart enough to ignore almost any inlining request that doesn't beggar a lookin for itself. Only the simplest and shortest functions manage to convince the compiler to inline them ... Unfortunately, most C++ programmer are *not* that smart. They will *manually* inline scores of simple functions until they have a few complicated functions with hundreds of lines of code in each one. Quote: and that too needs the inline directive or being defined within the body of the class. The purpose of inline functions is to encourage programmers to decompose their functions into smaller functions and allow the compiler to inline them *automatically*. The result should be programs that are easier to read, understand and maintain without sacrificing performance or efficiency. But this isn't possible for most C++ compilers is you stuff the the functions into a separate translation unit where the compiler can't see them. I'm guessing from your remarks that you write big fat functions where you have manually inlined the same functions repeatedly so that they are bloated by by design. The point is that inline functions are *not* really about performance, efficiency or code bloat. They are about encouraging good programming practice. The eliminate all of the excuses for manual inlining and large complicated functions. Back to top Ioannis Vranos Guest Posted: Sat Sep 25, 2004 6:00 am    Post subject: Re: inline functions E. Robert Tisdale wrote: Quote: The point is that inline functions are *not* really about performance, efficiency or code bloat. They are about encouraging good programming practice. The eliminate all of the excuses for manual inlining and large complicated functions. No, the purpose of inline functions is inlining and thus optimisation. That implies that only small functions should be inlined to increase run-time efficiency of these and not cause code bloat at the same time. The same applies for inline member functions. -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top JKop Guest Posted: Sat Sep 25, 2004 11:59 am    Post subject: Re: inline functions Ioannis Vranos posted: Quote: E. Robert Tisdale wrote: The point is that inline functions are *not* really about performance, efficiency or code bloat. They are about encouraging good programming practice. The eliminate all of the excuses for manual inlining and large complicated functions. No, the purpose of inline functions is inlining and thus optimisation. That implies that only small functions should be inlined to increase run-time efficiency of these and not cause code bloat at the same time. The same applies for inline member functions. One thing I think I should just throw in there... On some platforms you can actually *slow* a program down by inlining its functions. One example is Windows. There's a certain figure for executable code size, which once you go past it, a new page file thingie or whatever needs to be made. -JKop Back to top Ioannis Vranos Guest Posted: Sat Sep 25, 2004 5:15 pm    Post subject: Re: inline functions JKop wrote: Quote: One thing I think I should just throw in there... On some platforms you can actually *slow* a program down by inlining its functions. One example is Windows. There's a certain figure for executable code size, which once you go past it, a new page file thingie or whatever needs to be made. This info is not much clear. A new swap file is created when the space of the current one is exceeded. A swap file is used for an application mainly when no more physical RAM is available. Also an executable file is seriously increased by inline, when inline is not used properly. -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top E. Robert Tisdale Guest Posted: Sun Sep 26, 2004 12:13 am    Post subject: Re: inline functions Ioannis Vranos wrote: Quote: E. Robert Tisdale wrote: The point is that inline functions are *not* really about performance, efficiency or code bloat. They are about encouraging good programming practice. The eliminate all of the excuses for manual inlining and large complicated functions. No, the purpose of inline functions is inlining and thus optimisation. That implies that only small functions should be inlined to increase run-time efficiency of these and not cause code bloat at the same time. The same applies for inline member functions. But that begs the question, "Why do you have large functions?" Examine one of your larger functions and your will probably find that you have *manually* inline'd a lot of code that really should be executed by function calls. Why don't you decompose your large function into smaller functions? Why do you write large functions composed of largely redundant code? Back to top Ioannis Vranos Guest Posted: Sun Sep 26, 2004 3:24 am    Post subject: Re: inline functions E. Robert Tisdale wrote: Quote: But that begs the question, "Why do you have large functions?" Examine one of your larger functions and your will probably find that you have *manually* inline'd a lot of code that really should be executed by function calls. Why don't you decompose your large function into smaller functions? Why do you write large functions composed of largely redundant code? I suppose your "whys" above are not aimed to me personally, but are philosophical whys. Well yes, functions and methods should be small, but not all small functions must be inlined. Generally, only those that are accessed frequently. Always it depends on the situation. -- Ioannis Vranos http://www23.brinkster.com/noicys Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language (comp.lang.c++) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.