What is practical difference between `inline` and `template`?
We have 2 methods to declare function in header-only library. They are inline
and template<class = void>
. In boost
source code I can see both variants. Example follows:
inline void my_header_only_function(void)
// Do something...
return;
template<class = void> void my_header_only_function(void)
// Do something...
return;
I know what is difference according to C++ standard. However, any C++ compiler is much more than just standard, and also standard is unclear often.
In situation where template argument is never used and where it is not related to recursive variadic template, is there (and what is) practical difference between 2 variants for mainstream compilers?
c++
|
show 11 more comments
We have 2 methods to declare function in header-only library. They are inline
and template<class = void>
. In boost
source code I can see both variants. Example follows:
inline void my_header_only_function(void)
// Do something...
return;
template<class = void> void my_header_only_function(void)
// Do something...
return;
I know what is difference according to C++ standard. However, any C++ compiler is much more than just standard, and also standard is unclear often.
In situation where template argument is never used and where it is not related to recursive variadic template, is there (and what is) practical difference between 2 variants for mainstream compilers?
c++
2
I fail to see where the template solution is better than the inline one.
– YSC
Nov 15 '18 at 9:10
3
Thenmy_header_only_function<int>
,my_header_only_function<char>
, andmy_header_only_function<>
are three separate inline functions that implement the same logic but operate on different static data.
– StoryTeller
Nov 15 '18 at 9:13
4
"In boost source code I can see both variants" - I think it would be better to post those variants, I feel like something is missing here
– VTT
Nov 15 '18 at 9:13
1
@Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
– geza
Nov 15 '18 at 9:16
1
@chris, as far as I understand mainstream compilers ignoreinline
keyword often and in practice do inline on theirs own discretion. Real inlining depend on optimization level much more that on keyword; keyword is just hint, so I am not sure whether compiler will inline the function and will not inline template in practice.
– Vitaliy
Nov 15 '18 at 9:20
|
show 11 more comments
We have 2 methods to declare function in header-only library. They are inline
and template<class = void>
. In boost
source code I can see both variants. Example follows:
inline void my_header_only_function(void)
// Do something...
return;
template<class = void> void my_header_only_function(void)
// Do something...
return;
I know what is difference according to C++ standard. However, any C++ compiler is much more than just standard, and also standard is unclear often.
In situation where template argument is never used and where it is not related to recursive variadic template, is there (and what is) practical difference between 2 variants for mainstream compilers?
c++
We have 2 methods to declare function in header-only library. They are inline
and template<class = void>
. In boost
source code I can see both variants. Example follows:
inline void my_header_only_function(void)
// Do something...
return;
template<class = void> void my_header_only_function(void)
// Do something...
return;
I know what is difference according to C++ standard. However, any C++ compiler is much more than just standard, and also standard is unclear often.
In situation where template argument is never used and where it is not related to recursive variadic template, is there (and what is) practical difference between 2 variants for mainstream compilers?
c++
c++
edited Nov 15 '18 at 9:32
VTT
25.6k42447
25.6k42447
asked Nov 15 '18 at 9:07
VitaliyVitaliy
1,92932544
1,92932544
2
I fail to see where the template solution is better than the inline one.
– YSC
Nov 15 '18 at 9:10
3
Thenmy_header_only_function<int>
,my_header_only_function<char>
, andmy_header_only_function<>
are three separate inline functions that implement the same logic but operate on different static data.
– StoryTeller
Nov 15 '18 at 9:13
4
"In boost source code I can see both variants" - I think it would be better to post those variants, I feel like something is missing here
– VTT
Nov 15 '18 at 9:13
1
@Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
– geza
Nov 15 '18 at 9:16
1
@chris, as far as I understand mainstream compilers ignoreinline
keyword often and in practice do inline on theirs own discretion. Real inlining depend on optimization level much more that on keyword; keyword is just hint, so I am not sure whether compiler will inline the function and will not inline template in practice.
– Vitaliy
Nov 15 '18 at 9:20
|
show 11 more comments
2
I fail to see where the template solution is better than the inline one.
– YSC
Nov 15 '18 at 9:10
3
Thenmy_header_only_function<int>
,my_header_only_function<char>
, andmy_header_only_function<>
are three separate inline functions that implement the same logic but operate on different static data.
– StoryTeller
Nov 15 '18 at 9:13
4
"In boost source code I can see both variants" - I think it would be better to post those variants, I feel like something is missing here
– VTT
Nov 15 '18 at 9:13
1
@Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
– geza
Nov 15 '18 at 9:16
1
@chris, as far as I understand mainstream compilers ignoreinline
keyword often and in practice do inline on theirs own discretion. Real inlining depend on optimization level much more that on keyword; keyword is just hint, so I am not sure whether compiler will inline the function and will not inline template in practice.
– Vitaliy
Nov 15 '18 at 9:20
2
2
I fail to see where the template solution is better than the inline one.
– YSC
Nov 15 '18 at 9:10
I fail to see where the template solution is better than the inline one.
– YSC
Nov 15 '18 at 9:10
3
3
Then
my_header_only_function<int>
, my_header_only_function<char>
, and my_header_only_function<>
are three separate inline functions that implement the same logic but operate on different static data.– StoryTeller
Nov 15 '18 at 9:13
Then
my_header_only_function<int>
, my_header_only_function<char>
, and my_header_only_function<>
are three separate inline functions that implement the same logic but operate on different static data.– StoryTeller
Nov 15 '18 at 9:13
4
4
"In boost source code I can see both variants" - I think it would be better to post those variants, I feel like something is missing here
– VTT
Nov 15 '18 at 9:13
"In boost source code I can see both variants" - I think it would be better to post those variants, I feel like something is missing here
– VTT
Nov 15 '18 at 9:13
1
1
@Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
– geza
Nov 15 '18 at 9:16
@Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
– geza
Nov 15 '18 at 9:16
1
1
@chris, as far as I understand mainstream compilers ignore
inline
keyword often and in practice do inline on theirs own discretion. Real inlining depend on optimization level much more that on keyword; keyword is just hint, so I am not sure whether compiler will inline the function and will not inline template in practice.– Vitaliy
Nov 15 '18 at 9:20
@chris, as far as I understand mainstream compilers ignore
inline
keyword often and in practice do inline on theirs own discretion. Real inlining depend on optimization level much more that on keyword; keyword is just hint, so I am not sure whether compiler will inline the function and will not inline template in practice.– Vitaliy
Nov 15 '18 at 9:20
|
show 11 more comments
3 Answers
3
active
oldest
votes
I think this can be used as a weird way to allow library extension (or mocking) from outside library code by providing specialization for void
or a non-template version of the function in the same namespace:
#include <iostream>
template<class = void>
int
foo(int data)
::std::cout << "template" << std::endl;
return data;
// somewhere else
int
foo(int data)
::std::cout << "non-template" << std::endl;
return data;
int main()
foo(1); // non template overload is selected
return 0;
online compiler
2
It looks like you are right, I didn't think about that. For sure it is practical difference, we can override template with inline or non-inline function.
– Vitaliy
Nov 15 '18 at 9:27
This is actually a nice trick.
– YSC
Nov 15 '18 at 9:30
1
I mean thattemplate <> int foo<void>(int data) mock();
is an alternative toint foo(int data) mock();
. but both ways are risky with ODR or is partial mocking Demo.
– Jarod42
Nov 15 '18 at 9:40
1
@geza - Neither isstd
a "special" namespace. Those restrictions are imposed to prevent libraries and user code from stepping on each other's toes. So "works in most cases" isn't refuting much. And just because this answer offers a nice explanation doesn't mean it's the explanation for boost itself.
– StoryTeller
Nov 15 '18 at 9:57
1
@StoryTeller Well,std
is a "special" namespace because the standard explicitly makes most cases of putting stuff insidestd
Undefined Behaviour.
– Angew
Nov 15 '18 at 10:59
|
show 14 more comments
One difference is that binary code for the function may become part of the generated object file even if the function is never used in that file, but there will never be any code for the template if it's not used.
Can you please write any reference that proofs that any compiler will not discard unused function from binary file on optimization stage?
– Vitaliy
Nov 15 '18 at 9:25
@Vitaliy Not really, that's why I wrote "may become", not "will become."
– Angew
Nov 15 '18 at 9:26
It is reasonably common that compilers don't remove unused functions - it sort of breaks the separate compilation model, which means a function defined in one compilation unit needs to be called from another. Very few linkers (the program that combine objects into an executable) even check that any functions which are defined are never used, let alone remove unused functions. Whereas the compiler does not emit code for a template UNLESS the template is either used (resulting in implicit instantiation) or explicitly instantiated.
– Peter
Nov 15 '18 at 9:35
@Peter: compilers don't emit code for non-used inline functions either. At least, I've never see one.
– geza
Nov 15 '18 at 9:37
In that particular boost header all those template functions are always immediately instantiated to be used in non-template functions.
– VTT
Nov 15 '18 at 9:47
add a comment |
I'm the author of Beast. Hopefully I will be able to shed some light on why you see one versus the other. It really is very simple, the template seems less likely to be inlined into calling functions, bloating the code needlessly. I know that "inline" is really only supposed to mean "remove duplicate definitions" but sometimes compiler implementors get overzealous. The template thing is a little bit harder on the compile (Travis craps out sometimes at only 2GB RAM). So I decided to try writing some new stuff using the "inline" keyword. I still don't know how I feel about it.
The short answer is that I was doing it one way for a long time and then I briefly did it the other way for no particularly strong reason. Sorry if that is not as exciting as the other theories! (which were very interesting in fact)
Why not useBOOST_NOINLINE
then?
– VTT
Dec 11 '18 at 12:05
Didn't know about that!!!
– Vinnie Falco
Dec 11 '18 at 20:56
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53315816%2fwhat-is-practical-difference-between-inline-and-templateclass-void%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think this can be used as a weird way to allow library extension (or mocking) from outside library code by providing specialization for void
or a non-template version of the function in the same namespace:
#include <iostream>
template<class = void>
int
foo(int data)
::std::cout << "template" << std::endl;
return data;
// somewhere else
int
foo(int data)
::std::cout << "non-template" << std::endl;
return data;
int main()
foo(1); // non template overload is selected
return 0;
online compiler
2
It looks like you are right, I didn't think about that. For sure it is practical difference, we can override template with inline or non-inline function.
– Vitaliy
Nov 15 '18 at 9:27
This is actually a nice trick.
– YSC
Nov 15 '18 at 9:30
1
I mean thattemplate <> int foo<void>(int data) mock();
is an alternative toint foo(int data) mock();
. but both ways are risky with ODR or is partial mocking Demo.
– Jarod42
Nov 15 '18 at 9:40
1
@geza - Neither isstd
a "special" namespace. Those restrictions are imposed to prevent libraries and user code from stepping on each other's toes. So "works in most cases" isn't refuting much. And just because this answer offers a nice explanation doesn't mean it's the explanation for boost itself.
– StoryTeller
Nov 15 '18 at 9:57
1
@StoryTeller Well,std
is a "special" namespace because the standard explicitly makes most cases of putting stuff insidestd
Undefined Behaviour.
– Angew
Nov 15 '18 at 10:59
|
show 14 more comments
I think this can be used as a weird way to allow library extension (or mocking) from outside library code by providing specialization for void
or a non-template version of the function in the same namespace:
#include <iostream>
template<class = void>
int
foo(int data)
::std::cout << "template" << std::endl;
return data;
// somewhere else
int
foo(int data)
::std::cout << "non-template" << std::endl;
return data;
int main()
foo(1); // non template overload is selected
return 0;
online compiler
2
It looks like you are right, I didn't think about that. For sure it is practical difference, we can override template with inline or non-inline function.
– Vitaliy
Nov 15 '18 at 9:27
This is actually a nice trick.
– YSC
Nov 15 '18 at 9:30
1
I mean thattemplate <> int foo<void>(int data) mock();
is an alternative toint foo(int data) mock();
. but both ways are risky with ODR or is partial mocking Demo.
– Jarod42
Nov 15 '18 at 9:40
1
@geza - Neither isstd
a "special" namespace. Those restrictions are imposed to prevent libraries and user code from stepping on each other's toes. So "works in most cases" isn't refuting much. And just because this answer offers a nice explanation doesn't mean it's the explanation for boost itself.
– StoryTeller
Nov 15 '18 at 9:57
1
@StoryTeller Well,std
is a "special" namespace because the standard explicitly makes most cases of putting stuff insidestd
Undefined Behaviour.
– Angew
Nov 15 '18 at 10:59
|
show 14 more comments
I think this can be used as a weird way to allow library extension (or mocking) from outside library code by providing specialization for void
or a non-template version of the function in the same namespace:
#include <iostream>
template<class = void>
int
foo(int data)
::std::cout << "template" << std::endl;
return data;
// somewhere else
int
foo(int data)
::std::cout << "non-template" << std::endl;
return data;
int main()
foo(1); // non template overload is selected
return 0;
online compiler
I think this can be used as a weird way to allow library extension (or mocking) from outside library code by providing specialization for void
or a non-template version of the function in the same namespace:
#include <iostream>
template<class = void>
int
foo(int data)
::std::cout << "template" << std::endl;
return data;
// somewhere else
int
foo(int data)
::std::cout << "non-template" << std::endl;
return data;
int main()
foo(1); // non template overload is selected
return 0;
online compiler
edited Nov 15 '18 at 9:45
answered Nov 15 '18 at 9:25
VTTVTT
25.6k42447
25.6k42447
2
It looks like you are right, I didn't think about that. For sure it is practical difference, we can override template with inline or non-inline function.
– Vitaliy
Nov 15 '18 at 9:27
This is actually a nice trick.
– YSC
Nov 15 '18 at 9:30
1
I mean thattemplate <> int foo<void>(int data) mock();
is an alternative toint foo(int data) mock();
. but both ways are risky with ODR or is partial mocking Demo.
– Jarod42
Nov 15 '18 at 9:40
1
@geza - Neither isstd
a "special" namespace. Those restrictions are imposed to prevent libraries and user code from stepping on each other's toes. So "works in most cases" isn't refuting much. And just because this answer offers a nice explanation doesn't mean it's the explanation for boost itself.
– StoryTeller
Nov 15 '18 at 9:57
1
@StoryTeller Well,std
is a "special" namespace because the standard explicitly makes most cases of putting stuff insidestd
Undefined Behaviour.
– Angew
Nov 15 '18 at 10:59
|
show 14 more comments
2
It looks like you are right, I didn't think about that. For sure it is practical difference, we can override template with inline or non-inline function.
– Vitaliy
Nov 15 '18 at 9:27
This is actually a nice trick.
– YSC
Nov 15 '18 at 9:30
1
I mean thattemplate <> int foo<void>(int data) mock();
is an alternative toint foo(int data) mock();
. but both ways are risky with ODR or is partial mocking Demo.
– Jarod42
Nov 15 '18 at 9:40
1
@geza - Neither isstd
a "special" namespace. Those restrictions are imposed to prevent libraries and user code from stepping on each other's toes. So "works in most cases" isn't refuting much. And just because this answer offers a nice explanation doesn't mean it's the explanation for boost itself.
– StoryTeller
Nov 15 '18 at 9:57
1
@StoryTeller Well,std
is a "special" namespace because the standard explicitly makes most cases of putting stuff insidestd
Undefined Behaviour.
– Angew
Nov 15 '18 at 10:59
2
2
It looks like you are right, I didn't think about that. For sure it is practical difference, we can override template with inline or non-inline function.
– Vitaliy
Nov 15 '18 at 9:27
It looks like you are right, I didn't think about that. For sure it is practical difference, we can override template with inline or non-inline function.
– Vitaliy
Nov 15 '18 at 9:27
This is actually a nice trick.
– YSC
Nov 15 '18 at 9:30
This is actually a nice trick.
– YSC
Nov 15 '18 at 9:30
1
1
I mean that
template <> int foo<void>(int data) mock();
is an alternative to int foo(int data) mock();
. but both ways are risky with ODR or is partial mocking Demo.– Jarod42
Nov 15 '18 at 9:40
I mean that
template <> int foo<void>(int data) mock();
is an alternative to int foo(int data) mock();
. but both ways are risky with ODR or is partial mocking Demo.– Jarod42
Nov 15 '18 at 9:40
1
1
@geza - Neither is
std
a "special" namespace. Those restrictions are imposed to prevent libraries and user code from stepping on each other's toes. So "works in most cases" isn't refuting much. And just because this answer offers a nice explanation doesn't mean it's the explanation for boost itself.– StoryTeller
Nov 15 '18 at 9:57
@geza - Neither is
std
a "special" namespace. Those restrictions are imposed to prevent libraries and user code from stepping on each other's toes. So "works in most cases" isn't refuting much. And just because this answer offers a nice explanation doesn't mean it's the explanation for boost itself.– StoryTeller
Nov 15 '18 at 9:57
1
1
@StoryTeller Well,
std
is a "special" namespace because the standard explicitly makes most cases of putting stuff inside std
Undefined Behaviour.– Angew
Nov 15 '18 at 10:59
@StoryTeller Well,
std
is a "special" namespace because the standard explicitly makes most cases of putting stuff inside std
Undefined Behaviour.– Angew
Nov 15 '18 at 10:59
|
show 14 more comments
One difference is that binary code for the function may become part of the generated object file even if the function is never used in that file, but there will never be any code for the template if it's not used.
Can you please write any reference that proofs that any compiler will not discard unused function from binary file on optimization stage?
– Vitaliy
Nov 15 '18 at 9:25
@Vitaliy Not really, that's why I wrote "may become", not "will become."
– Angew
Nov 15 '18 at 9:26
It is reasonably common that compilers don't remove unused functions - it sort of breaks the separate compilation model, which means a function defined in one compilation unit needs to be called from another. Very few linkers (the program that combine objects into an executable) even check that any functions which are defined are never used, let alone remove unused functions. Whereas the compiler does not emit code for a template UNLESS the template is either used (resulting in implicit instantiation) or explicitly instantiated.
– Peter
Nov 15 '18 at 9:35
@Peter: compilers don't emit code for non-used inline functions either. At least, I've never see one.
– geza
Nov 15 '18 at 9:37
In that particular boost header all those template functions are always immediately instantiated to be used in non-template functions.
– VTT
Nov 15 '18 at 9:47
add a comment |
One difference is that binary code for the function may become part of the generated object file even if the function is never used in that file, but there will never be any code for the template if it's not used.
Can you please write any reference that proofs that any compiler will not discard unused function from binary file on optimization stage?
– Vitaliy
Nov 15 '18 at 9:25
@Vitaliy Not really, that's why I wrote "may become", not "will become."
– Angew
Nov 15 '18 at 9:26
It is reasonably common that compilers don't remove unused functions - it sort of breaks the separate compilation model, which means a function defined in one compilation unit needs to be called from another. Very few linkers (the program that combine objects into an executable) even check that any functions which are defined are never used, let alone remove unused functions. Whereas the compiler does not emit code for a template UNLESS the template is either used (resulting in implicit instantiation) or explicitly instantiated.
– Peter
Nov 15 '18 at 9:35
@Peter: compilers don't emit code for non-used inline functions either. At least, I've never see one.
– geza
Nov 15 '18 at 9:37
In that particular boost header all those template functions are always immediately instantiated to be used in non-template functions.
– VTT
Nov 15 '18 at 9:47
add a comment |
One difference is that binary code for the function may become part of the generated object file even if the function is never used in that file, but there will never be any code for the template if it's not used.
One difference is that binary code for the function may become part of the generated object file even if the function is never used in that file, but there will never be any code for the template if it's not used.
answered Nov 15 '18 at 9:23
AngewAngew
133k11257349
133k11257349
Can you please write any reference that proofs that any compiler will not discard unused function from binary file on optimization stage?
– Vitaliy
Nov 15 '18 at 9:25
@Vitaliy Not really, that's why I wrote "may become", not "will become."
– Angew
Nov 15 '18 at 9:26
It is reasonably common that compilers don't remove unused functions - it sort of breaks the separate compilation model, which means a function defined in one compilation unit needs to be called from another. Very few linkers (the program that combine objects into an executable) even check that any functions which are defined are never used, let alone remove unused functions. Whereas the compiler does not emit code for a template UNLESS the template is either used (resulting in implicit instantiation) or explicitly instantiated.
– Peter
Nov 15 '18 at 9:35
@Peter: compilers don't emit code for non-used inline functions either. At least, I've never see one.
– geza
Nov 15 '18 at 9:37
In that particular boost header all those template functions are always immediately instantiated to be used in non-template functions.
– VTT
Nov 15 '18 at 9:47
add a comment |
Can you please write any reference that proofs that any compiler will not discard unused function from binary file on optimization stage?
– Vitaliy
Nov 15 '18 at 9:25
@Vitaliy Not really, that's why I wrote "may become", not "will become."
– Angew
Nov 15 '18 at 9:26
It is reasonably common that compilers don't remove unused functions - it sort of breaks the separate compilation model, which means a function defined in one compilation unit needs to be called from another. Very few linkers (the program that combine objects into an executable) even check that any functions which are defined are never used, let alone remove unused functions. Whereas the compiler does not emit code for a template UNLESS the template is either used (resulting in implicit instantiation) or explicitly instantiated.
– Peter
Nov 15 '18 at 9:35
@Peter: compilers don't emit code for non-used inline functions either. At least, I've never see one.
– geza
Nov 15 '18 at 9:37
In that particular boost header all those template functions are always immediately instantiated to be used in non-template functions.
– VTT
Nov 15 '18 at 9:47
Can you please write any reference that proofs that any compiler will not discard unused function from binary file on optimization stage?
– Vitaliy
Nov 15 '18 at 9:25
Can you please write any reference that proofs that any compiler will not discard unused function from binary file on optimization stage?
– Vitaliy
Nov 15 '18 at 9:25
@Vitaliy Not really, that's why I wrote "may become", not "will become."
– Angew
Nov 15 '18 at 9:26
@Vitaliy Not really, that's why I wrote "may become", not "will become."
– Angew
Nov 15 '18 at 9:26
It is reasonably common that compilers don't remove unused functions - it sort of breaks the separate compilation model, which means a function defined in one compilation unit needs to be called from another. Very few linkers (the program that combine objects into an executable) even check that any functions which are defined are never used, let alone remove unused functions. Whereas the compiler does not emit code for a template UNLESS the template is either used (resulting in implicit instantiation) or explicitly instantiated.
– Peter
Nov 15 '18 at 9:35
It is reasonably common that compilers don't remove unused functions - it sort of breaks the separate compilation model, which means a function defined in one compilation unit needs to be called from another. Very few linkers (the program that combine objects into an executable) even check that any functions which are defined are never used, let alone remove unused functions. Whereas the compiler does not emit code for a template UNLESS the template is either used (resulting in implicit instantiation) or explicitly instantiated.
– Peter
Nov 15 '18 at 9:35
@Peter: compilers don't emit code for non-used inline functions either. At least, I've never see one.
– geza
Nov 15 '18 at 9:37
@Peter: compilers don't emit code for non-used inline functions either. At least, I've never see one.
– geza
Nov 15 '18 at 9:37
In that particular boost header all those template functions are always immediately instantiated to be used in non-template functions.
– VTT
Nov 15 '18 at 9:47
In that particular boost header all those template functions are always immediately instantiated to be used in non-template functions.
– VTT
Nov 15 '18 at 9:47
add a comment |
I'm the author of Beast. Hopefully I will be able to shed some light on why you see one versus the other. It really is very simple, the template seems less likely to be inlined into calling functions, bloating the code needlessly. I know that "inline" is really only supposed to mean "remove duplicate definitions" but sometimes compiler implementors get overzealous. The template thing is a little bit harder on the compile (Travis craps out sometimes at only 2GB RAM). So I decided to try writing some new stuff using the "inline" keyword. I still don't know how I feel about it.
The short answer is that I was doing it one way for a long time and then I briefly did it the other way for no particularly strong reason. Sorry if that is not as exciting as the other theories! (which were very interesting in fact)
Why not useBOOST_NOINLINE
then?
– VTT
Dec 11 '18 at 12:05
Didn't know about that!!!
– Vinnie Falco
Dec 11 '18 at 20:56
add a comment |
I'm the author of Beast. Hopefully I will be able to shed some light on why you see one versus the other. It really is very simple, the template seems less likely to be inlined into calling functions, bloating the code needlessly. I know that "inline" is really only supposed to mean "remove duplicate definitions" but sometimes compiler implementors get overzealous. The template thing is a little bit harder on the compile (Travis craps out sometimes at only 2GB RAM). So I decided to try writing some new stuff using the "inline" keyword. I still don't know how I feel about it.
The short answer is that I was doing it one way for a long time and then I briefly did it the other way for no particularly strong reason. Sorry if that is not as exciting as the other theories! (which were very interesting in fact)
Why not useBOOST_NOINLINE
then?
– VTT
Dec 11 '18 at 12:05
Didn't know about that!!!
– Vinnie Falco
Dec 11 '18 at 20:56
add a comment |
I'm the author of Beast. Hopefully I will be able to shed some light on why you see one versus the other. It really is very simple, the template seems less likely to be inlined into calling functions, bloating the code needlessly. I know that "inline" is really only supposed to mean "remove duplicate definitions" but sometimes compiler implementors get overzealous. The template thing is a little bit harder on the compile (Travis craps out sometimes at only 2GB RAM). So I decided to try writing some new stuff using the "inline" keyword. I still don't know how I feel about it.
The short answer is that I was doing it one way for a long time and then I briefly did it the other way for no particularly strong reason. Sorry if that is not as exciting as the other theories! (which were very interesting in fact)
I'm the author of Beast. Hopefully I will be able to shed some light on why you see one versus the other. It really is very simple, the template seems less likely to be inlined into calling functions, bloating the code needlessly. I know that "inline" is really only supposed to mean "remove duplicate definitions" but sometimes compiler implementors get overzealous. The template thing is a little bit harder on the compile (Travis craps out sometimes at only 2GB RAM). So I decided to try writing some new stuff using the "inline" keyword. I still don't know how I feel about it.
The short answer is that I was doing it one way for a long time and then I briefly did it the other way for no particularly strong reason. Sorry if that is not as exciting as the other theories! (which were very interesting in fact)
answered Nov 16 '18 at 2:19
Vinnie FalcoVinnie Falco
2,8061532
2,8061532
Why not useBOOST_NOINLINE
then?
– VTT
Dec 11 '18 at 12:05
Didn't know about that!!!
– Vinnie Falco
Dec 11 '18 at 20:56
add a comment |
Why not useBOOST_NOINLINE
then?
– VTT
Dec 11 '18 at 12:05
Didn't know about that!!!
– Vinnie Falco
Dec 11 '18 at 20:56
Why not use
BOOST_NOINLINE
then?– VTT
Dec 11 '18 at 12:05
Why not use
BOOST_NOINLINE
then?– VTT
Dec 11 '18 at 12:05
Didn't know about that!!!
– Vinnie Falco
Dec 11 '18 at 20:56
Didn't know about that!!!
– Vinnie Falco
Dec 11 '18 at 20:56
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53315816%2fwhat-is-practical-difference-between-inline-and-templateclass-void%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
I fail to see where the template solution is better than the inline one.
– YSC
Nov 15 '18 at 9:10
3
Then
my_header_only_function<int>
,my_header_only_function<char>
, andmy_header_only_function<>
are three separate inline functions that implement the same logic but operate on different static data.– StoryTeller
Nov 15 '18 at 9:13
4
"In boost source code I can see both variants" - I think it would be better to post those variants, I feel like something is missing here
– VTT
Nov 15 '18 at 9:13
1
@Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
– geza
Nov 15 '18 at 9:16
1
@chris, as far as I understand mainstream compilers ignore
inline
keyword often and in practice do inline on theirs own discretion. Real inlining depend on optimization level much more that on keyword; keyword is just hint, so I am not sure whether compiler will inline the function and will not inline template in practice.– Vitaliy
Nov 15 '18 at 9:20