Inline functions in boost/utility
Hi Looking through assembly code of simple test produced by gcc with optimization, I've noticed that free functions in utility/value_init.hpp (get and set) are not declared as inline, though its body consist only of prologue and epilogue. Is there any reason for this or just a bug?
Timenkov Yuri wrote:
Looking through assembly code of simple test produced by gcc with optimization, I've noticed that free functions in utility/value_init.hpp (get and set) are not declared as inline, though its body consist only of prologue and epilogue.
Is there any reason for this or just a bug?
Sorry, I don't really get it. First of all, utility/value_init.hpp doesn't have a "set". Do you mean "swap"? But secondly it's really up to the compiler whether or not those functions are inlined. An "inline" keyword would only be a hint to the compiler to do so, in this case. But as value_init.hpp provides the complete definitions of the function templates, it shouldn't be hard for the compiler to apply inlining. Are you saying that gcc would /only/ inline those functions, when they are declared as inline? Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
On Tue, Feb 10, 2009 at 5:59 PM, Niels Dekker - mail address until 2010-10-10 <niels_address_until_2010-10-10@xs4all.nl> wrote:
Timenkov Yuri wrote:
Looking through assembly code of simple test produced by gcc with
optimization, I've noticed that free functions in utility/value_init.hpp (get and set) are not declared as inline, though its body consist only of prologue and epilogue.
Is there any reason for this or just a bug?
Sorry, I don't really get it. First of all, utility/value_init.hpp doesn't have a "set". Do you mean "swap"? But secondly it's really up to the compiler whether or not those functions are inlined. An "inline" keyword would only be a hint to the compiler to do so, in this case. But as value_init.hpp provides the complete definitions of the function templates, it shouldn't be hard for the compiler to apply inlining. Are you saying that gcc would /only/ inline those functions, when they are declared as inline?
Yuri, Niels is right. This article might be of interest for you. http://www.gotw.ca/gotw/033.htm There are cases where you must declare a function as inline, otherwise a linker will have ambiguity of more than one identical symbols and fail to link: header.h void foo() { // ... } cpp_file1.cpp #include "header.h" ... cpp_file2.cpp #include "header.h" ... This app will compile, but there will be 2 implementations of void foo(), since each compilation unit will generate it's own one. Linker will fail due to ambiguity which symbol is the right one. To fix this problem you have to either leave a function declaration in the header and move its definition into a cpp file or declare this function as inline. Best Regards, Ovanes
Ovanes Markarian escribió:
On Tue, Feb 10, 2009 at 5:59 PM, Niels Dekker - mail address until 2010-10-10 <niels_address_until_2010-10-10@xs4all.nl <mailto:niels_address_until_2010-10-10@xs4all.nl>> wrote:
Timenkov Yuri wrote:
Looking through assembly code of simple test produced by gcc with optimization, I've noticed that free functions in utility/value_init.hpp (get and set) are not declared as inline, though its body consist only of prologue and epilogue.
Is there any reason for this or just a bug?
Sorry, I don't really get it. First of all, utility/value_init.hpp doesn't have a "set". Do you mean "swap"? But secondly it's really up to the compiler whether or not those functions are inlined. An "inline" keyword would only be a hint to the compiler to do so, in this case. But as value_init.hpp provides the complete definitions of the function templates, it shouldn't be hard for the compiler to apply inlining. Are you saying that gcc would /only/ inline those functions, when they are declared as inline?
Yuri, Niels is right. This article might be of interest for you.
http://www.gotw.ca/gotw/033.htm
There are cases where you must declare a function as inline, otherwise a linker will have ambiguity of more than one identical symbols and fail to link:
Yep, but this does not apply to function templates, which can be defined in different translation units, with the only requirement that the definition coincides in each unit. See http://tinyurl.com/crkyl3 , and in particular the answer from Daveed Vandevoorde. AFAICS the get's in utility/value_init.hpp are all function templates. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Yep, but this does not apply to function templates, which can be defined in
different translation units, with the only requirement that the definition coincides in each unit. See http://tinyurl.com/crkyl3 , and in particular the answer from Daveed Vandevoorde. AFAICS the get's in utility/value_init.hpp are all function templates.
Yes, forgot about this.... Thanks! Ovanes.
On Tue, Feb 10, 2009 at 7:59 PM, Niels Dekker - mail address until 2010-10-10 <niels_address_until_2010-10-10@xs4all.nl> wrote:
Timenkov Yuri wrote:
Looking through assembly code of simple test produced by gcc with
optimization, I've noticed that free functions in utility/value_init.hpp (get and set) are not declared as inline, though its body consist only of prologue and epilogue.
Is there any reason for this or just a bug?
Sorry, I don't really get it. First of all, utility/value_init.hpp doesn't have a "set". Do you mean "swap"? But secondly it's really up to the compiler whether or not those functions are inlined. An "inline" keyword would only be a hint to the compiler to do so, in this case. But as value_init.hpp provides the complete definitions of the function templates, it shouldn't be hard for the compiler to apply inlining. Are you saying that gcc would /only/ inline those functions, when they are declared as inline?
Actually there are 2 get functions :) (one is const one), but when I glanced through this file I saw first get and assumed the second one should be set. As already said in this thread, they are template functions (therefore they can be defined in header), but since they aren't declared as inline, gcc doesn't try to inline them. I supposed this happened because member functions defined in class declaration are inline (I don't remember the exact paragraph of standard), so most of boost library may be inlined by compiler. But here developer might forgot to declare free function as inline too.
Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware<http://www.xs4all.nl/%7End/dekkerware> Scientific programmer at LKEB, Leiden University Medical Center
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (1)
-
joaquin＠tid.es -
Niels Dekker - mail address until 2010-10-10 -
Ovanes Markarian -
Timenkov Yuri