What is practical difference between `inline` and `template`?











up vote
16
down vote

favorite
1












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++







share|improve this question




















  • 2




    I fail to see where the template solution is better than the inline one.
    – YSC
    Nov 15 at 9:10






  • 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 at 9:13








  • 3




    "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 at 9:13






  • 1




    @Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
    – geza
    Nov 15 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 at 9:20

















up vote
16
down vote

favorite
1












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++







share|improve this question




















  • 2




    I fail to see where the template solution is better than the inline one.
    – YSC
    Nov 15 at 9:10






  • 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 at 9:13








  • 3




    "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 at 9:13






  • 1




    @Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
    – geza
    Nov 15 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 at 9:20















up vote
16
down vote

favorite
1









up vote
16
down vote

favorite
1






1





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++







share|improve this question















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++






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 at 9:32









VTT

23.1k32345




23.1k32345










asked Nov 15 at 9:07









Vitaliy

1,85532344




1,85532344








  • 2




    I fail to see where the template solution is better than the inline one.
    – YSC
    Nov 15 at 9:10






  • 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 at 9:13








  • 3




    "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 at 9:13






  • 1




    @Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
    – geza
    Nov 15 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 at 9:20
















  • 2




    I fail to see where the template solution is better than the inline one.
    – YSC
    Nov 15 at 9:10






  • 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 at 9:13








  • 3




    "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 at 9:13






  • 1




    @Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
    – geza
    Nov 15 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 at 9:20










2




2




I fail to see where the template solution is better than the inline one.
– YSC
Nov 15 at 9:10




I fail to see where the template solution is better than the inline one.
– YSC
Nov 15 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 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 at 9:13






3




3




"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 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 at 9:13




1




1




@Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
– geza
Nov 15 at 9:16




@Vitaliy: it's worse because it allows a fake non-used parameter for no reason.
– geza
Nov 15 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 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 at 9:20














3 Answers
3






active

oldest

votes

















up vote
8
down vote



accepted










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






share|improve this answer



















  • 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 at 9:27










  • This is actually a nice trick.
    – YSC
    Nov 15 at 9:30






  • 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 at 9:40








  • 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 at 9:57








  • 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 at 10:59


















up vote
7
down vote













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.






share|improve this answer





















  • 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 at 9:25










  • @Vitaliy Not really, that's why I wrote "may become", not "will become."
    – Angew
    Nov 15 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 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 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 at 9:47




















up vote
2
down vote













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)






share|improve this answer





















    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',
    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
    });


    }
    });














     

    draft saved


    draft discarded


















    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








    up vote
    8
    down vote



    accepted










    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






    share|improve this answer



















    • 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 at 9:27










    • This is actually a nice trick.
      – YSC
      Nov 15 at 9:30






    • 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 at 9:40








    • 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 at 9:57








    • 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 at 10:59















    up vote
    8
    down vote



    accepted










    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






    share|improve this answer



















    • 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 at 9:27










    • This is actually a nice trick.
      – YSC
      Nov 15 at 9:30






    • 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 at 9:40








    • 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 at 9:57








    • 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 at 10:59













    up vote
    8
    down vote



    accepted







    up vote
    8
    down vote



    accepted






    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






    share|improve this answer














    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







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 15 at 9:45

























    answered Nov 15 at 9:25









    VTT

    23.1k32345




    23.1k32345








    • 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 at 9:27










    • This is actually a nice trick.
      – YSC
      Nov 15 at 9:30






    • 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 at 9:40








    • 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 at 9:57








    • 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 at 10:59














    • 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 at 9:27










    • This is actually a nice trick.
      – YSC
      Nov 15 at 9:30






    • 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 at 9:40








    • 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 at 9:57








    • 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 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 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 at 9:27












    This is actually a nice trick.
    – YSC
    Nov 15 at 9:30




    This is actually a nice trick.
    – YSC
    Nov 15 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 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 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 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 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 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 at 10:59












    up vote
    7
    down vote













    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.






    share|improve this answer





















    • 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 at 9:25










    • @Vitaliy Not really, that's why I wrote "may become", not "will become."
      – Angew
      Nov 15 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 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 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 at 9:47

















    up vote
    7
    down vote













    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.






    share|improve this answer





















    • 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 at 9:25










    • @Vitaliy Not really, that's why I wrote "may become", not "will become."
      – Angew
      Nov 15 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 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 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 at 9:47















    up vote
    7
    down vote










    up vote
    7
    down vote









    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.






    share|improve this answer












    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 15 at 9:23









    Angew

    130k11245336




    130k11245336












    • 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 at 9:25










    • @Vitaliy Not really, that's why I wrote "may become", not "will become."
      – Angew
      Nov 15 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 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 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 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 at 9:25










    • @Vitaliy Not really, that's why I wrote "may become", not "will become."
      – Angew
      Nov 15 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 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 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 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 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 at 9:25












    @Vitaliy Not really, that's why I wrote "may become", not "will become."
    – Angew
    Nov 15 at 9:26




    @Vitaliy Not really, that's why I wrote "may become", not "will become."
    – Angew
    Nov 15 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 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 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 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 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 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 at 9:47












    up vote
    2
    down vote













    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)






    share|improve this answer

























      up vote
      2
      down vote













      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)






      share|improve this answer























        up vote
        2
        down vote










        up vote
        2
        down vote









        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)






        share|improve this answer












        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)







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 16 at 2:19









        Vinnie Falco

        2,4401432




        2,4401432






























             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            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





















































            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







            -

            Popular posts from this blog

            Plaza Victoria

            Image
            Plaza Victoria Plaza Victoria en 2017 Otros nombres Plaza de La Victoria Localización El Almendral, Valparaíso, Chile Vías adyacentes Chacabuco, Molina, Plaza Victoria y Edwards Creación 1841 Metro Bellavista Ubicación 33°02′46″S 71°37′11″O  /  -33.04624167, -71.61980833 Coordenadas: 33°02′46″S 71°37′11″O  /  -33.04624167, -71.61980833 [editar datos en Wikidata] La Plaza Victoria , también llamada Plaza de la Victoria , [ 1 ] ​ es una plaza ubicada en el sector El Almendral del plan de la ciudad de Valparaíso, Chile, de importancia patrimonial, que incluye valiosas estatuas y especies vegetales. [ 2 ] ​ La plaza se creó como tal en la primera mitad del siglo XIX, tomando previamente los nombres de Plaza Nueva y Plaza de Orrego . Si bien desde sus inicios tuvo relevancia histórica, no fue sino a partir de fines de los años 1860 cuando comenzó a cobrar mayor importancia y se convirtió en uno de los principales centros sociales de l...
            Read more

            Puebla de Zaragoza

            Image
            Para otros usos de este término, véase Puebla (desambiguación). Heroica Puebla de Zaragoza Localidad De arriba a abajo de izquierda a derecha: Estrella de Puebla, Volcán Popocatépetl, Catedral de Puebla, Monumento a Ignacio Zaragoza, Estadio Cuauhtémoc, Angelópolis y Vista panorámica de la ciudad. Escudo Otros nombres: El relicario de América/ La ciudad de los Ángeles/ La Angelópolis Lema: Muy noble y muy leal ciudad de Puebla de los Ángeles Heroica Puebla de Zaragoza Localización de Heroica Puebla de Zaragoza en México Heroica Puebla de Zaragoza Localización de Heroica Puebla de Zaragoza en Puebla Mapa interactivo Coordenadas 19°03′05″N 98°13′04″O  /  19.051388888889, -98.217777777778 Coordenadas: 19°03′05″N 98°13′04″O  /  19.051388888889, -98.217777777778 Idioma oficial Español Entidad Localidad  • País   México  • Estado Puebla  • Municipio Puebla Presidente municipal Claudia Rivera Vivanc...
            Read more

            Musa

            Image
            Para el género de plantas, véase Musa (planta). Apolo y la Nueve Musas En la mitología griega, las musas (en griego antiguo μοῦσαι « mousai» ) son, según los escritores más antiguos, las divinidades inspiradoras de las Artes: cada una de ellas está relacionada con ramas artísticas y del conocimiento. Son hijas de Zeus y de Mnemósine, compañeras del séquito de Apolo, dios olímpico de la música y patrón de las bellas artes, quien tuvo romances con cada una de ellas, dejando descendientes. Bajaban a la tierra a susurrar ideas e inspirar a aquellos mortales que las invocaran. En la época más arcaica eran las ninfas inspiradoras de las fuentes, en las cuales eran adoradas. Finalmente, alrededor de los siglos VIII-VII a. C. [ 1 ] ​ prevaleció en todo el territorio de la Hélade la adoración de las nueve Musas, que son Calíope, Clío, Erato, Euterpe, Melpómene, Polimnia, Talía, Terpsícore y Urania. El culto a las musas era originalmente de Tracia y Beocia, y fueron de vital impo...
            Read more