Why doesn't the standard consider a template constructor as a copy constructor?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







10















Here's the definition of copy constructor, [class.copy.ctor/1]:




A non-template constructor for class X is a copy constructor if its first parameter is of type X&, const X&, volatile X& or const volatile X&, and either there are no other parameters or else all other parameters have default arguments ([dcl.fct.default]).




Why does the standard forbid templates as copy constructor?



In this simple example, both constructors are copy constructors:



struct Foo {
Foo(const Foo &); // copy constructor
Foo(Foo &); // copy constructor
};


See this similar example:



struct Foo {
Foo() = default;

template <typename T>
Foo(T &) {
printf("heren");
}
};

int main() {
Foo a;
Foo b = a;
}


In this example, here will be printed. So it seems that my template constructor is a copy constructor, at least it behaves like one (it is called in a context where copy constructors are usually called).



Why is the "non-template" requirement there in the text?










share|improve this question

























  • Note: I'm note sure Foo b = a instantiates and calls Foo::Foo<Foo>(Foo&). It might rather call the implicitly declared copy constructor.

    – YSC
    35 mins ago













  • @YSC Both gcc and clang (tested on Coliru) actually do print "here" from this code.

    – Angew
    35 mins ago











  • @Angew maybe they are wrong then, in regard of [class.copy.ctor]/1 & /6.

    – YSC
    34 mins ago








  • 1





    What happens if you Foo c = std::move(a); ?

    – Caleth
    32 mins ago











  • see stackoverflow.com/a/24832212/3370124

    – Richard Critten
    30 mins ago


















10















Here's the definition of copy constructor, [class.copy.ctor/1]:




A non-template constructor for class X is a copy constructor if its first parameter is of type X&, const X&, volatile X& or const volatile X&, and either there are no other parameters or else all other parameters have default arguments ([dcl.fct.default]).




Why does the standard forbid templates as copy constructor?



In this simple example, both constructors are copy constructors:



struct Foo {
Foo(const Foo &); // copy constructor
Foo(Foo &); // copy constructor
};


See this similar example:



struct Foo {
Foo() = default;

template <typename T>
Foo(T &) {
printf("heren");
}
};

int main() {
Foo a;
Foo b = a;
}


In this example, here will be printed. So it seems that my template constructor is a copy constructor, at least it behaves like one (it is called in a context where copy constructors are usually called).



Why is the "non-template" requirement there in the text?










share|improve this question

























  • Note: I'm note sure Foo b = a instantiates and calls Foo::Foo<Foo>(Foo&). It might rather call the implicitly declared copy constructor.

    – YSC
    35 mins ago













  • @YSC Both gcc and clang (tested on Coliru) actually do print "here" from this code.

    – Angew
    35 mins ago











  • @Angew maybe they are wrong then, in regard of [class.copy.ctor]/1 & /6.

    – YSC
    34 mins ago








  • 1





    What happens if you Foo c = std::move(a); ?

    – Caleth
    32 mins ago











  • see stackoverflow.com/a/24832212/3370124

    – Richard Critten
    30 mins ago














10












10








10


3






Here's the definition of copy constructor, [class.copy.ctor/1]:




A non-template constructor for class X is a copy constructor if its first parameter is of type X&, const X&, volatile X& or const volatile X&, and either there are no other parameters or else all other parameters have default arguments ([dcl.fct.default]).




Why does the standard forbid templates as copy constructor?



In this simple example, both constructors are copy constructors:



struct Foo {
Foo(const Foo &); // copy constructor
Foo(Foo &); // copy constructor
};


See this similar example:



struct Foo {
Foo() = default;

template <typename T>
Foo(T &) {
printf("heren");
}
};

int main() {
Foo a;
Foo b = a;
}


In this example, here will be printed. So it seems that my template constructor is a copy constructor, at least it behaves like one (it is called in a context where copy constructors are usually called).



Why is the "non-template" requirement there in the text?










share|improve this question
















Here's the definition of copy constructor, [class.copy.ctor/1]:




A non-template constructor for class X is a copy constructor if its first parameter is of type X&, const X&, volatile X& or const volatile X&, and either there are no other parameters or else all other parameters have default arguments ([dcl.fct.default]).




Why does the standard forbid templates as copy constructor?



In this simple example, both constructors are copy constructors:



struct Foo {
Foo(const Foo &); // copy constructor
Foo(Foo &); // copy constructor
};


See this similar example:



struct Foo {
Foo() = default;

template <typename T>
Foo(T &) {
printf("heren");
}
};

int main() {
Foo a;
Foo b = a;
}


In this example, here will be printed. So it seems that my template constructor is a copy constructor, at least it behaves like one (it is called in a context where copy constructors are usually called).



Why is the "non-template" requirement there in the text?







c++ language-lawyer






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 41 mins ago









πάντα ῥεῖ

74.4k1077145




74.4k1077145










asked 44 mins ago









gezageza

14.1k33282




14.1k33282













  • Note: I'm note sure Foo b = a instantiates and calls Foo::Foo<Foo>(Foo&). It might rather call the implicitly declared copy constructor.

    – YSC
    35 mins ago













  • @YSC Both gcc and clang (tested on Coliru) actually do print "here" from this code.

    – Angew
    35 mins ago











  • @Angew maybe they are wrong then, in regard of [class.copy.ctor]/1 & /6.

    – YSC
    34 mins ago








  • 1





    What happens if you Foo c = std::move(a); ?

    – Caleth
    32 mins ago











  • see stackoverflow.com/a/24832212/3370124

    – Richard Critten
    30 mins ago



















  • Note: I'm note sure Foo b = a instantiates and calls Foo::Foo<Foo>(Foo&). It might rather call the implicitly declared copy constructor.

    – YSC
    35 mins ago













  • @YSC Both gcc and clang (tested on Coliru) actually do print "here" from this code.

    – Angew
    35 mins ago











  • @Angew maybe they are wrong then, in regard of [class.copy.ctor]/1 & /6.

    – YSC
    34 mins ago








  • 1





    What happens if you Foo c = std::move(a); ?

    – Caleth
    32 mins ago











  • see stackoverflow.com/a/24832212/3370124

    – Richard Critten
    30 mins ago

















Note: I'm note sure Foo b = a instantiates and calls Foo::Foo<Foo>(Foo&). It might rather call the implicitly declared copy constructor.

– YSC
35 mins ago







Note: I'm note sure Foo b = a instantiates and calls Foo::Foo<Foo>(Foo&). It might rather call the implicitly declared copy constructor.

– YSC
35 mins ago















@YSC Both gcc and clang (tested on Coliru) actually do print "here" from this code.

– Angew
35 mins ago





@YSC Both gcc and clang (tested on Coliru) actually do print "here" from this code.

– Angew
35 mins ago













@Angew maybe they are wrong then, in regard of [class.copy.ctor]/1 & /6.

– YSC
34 mins ago







@Angew maybe they are wrong then, in regard of [class.copy.ctor]/1 & /6.

– YSC
34 mins ago






1




1





What happens if you Foo c = std::move(a); ?

– Caleth
32 mins ago





What happens if you Foo c = std::move(a); ?

– Caleth
32 mins ago













see stackoverflow.com/a/24832212/3370124

– Richard Critten
30 mins ago





see stackoverflow.com/a/24832212/3370124

– Richard Critten
30 mins ago












3 Answers
3






active

oldest

votes


















7














Let's put templates aside for a second. If a class doesn't declare a copy c'tor, an implicitly defaulted one is generated. It may be defined as deleted, but it's defaulted nonetheless.



A member template is not a member function. Members are instantiated from it only when needed.



So how can a compiler know from the class definition alone whether or not a specialization with T = Foo will ever be needed? It can't. But it's exactly that on which it needs to base a decision of how to handle a potential need for an implicitly defaulted copy c'tor (AND move c'tor). That becomes messy.



The easiest approach is to exclude templates. We'll always have some copy c'tor anyway, it will do the correct thingTM by default, and will be favored by overload resolution because it's not instantiated from a template.






share|improve this answer



















  • 2





    You are always the correct thingTM.

    – Sombrero Chicken
    23 mins ago






  • 1





    What's your opinion on g++ & clang++ printing "here" in the program shown in the Q then?

    – YSC
    21 mins ago






  • 3





    So basically you say that this is because of the rule: "If the class definition does not explicitly declare a copy constructor, a non-explicit one is declared implicitly". And we still expect that the usual implicit copy constructor is defined, no matter of the templated constructor. Yep, this seems the explanation.

    – geza
    21 mins ago






  • 1





    @YSC: it is printed, because the parameter passed is not const, so the template is a better match than the implicit one. But it is confusing (for me) to not call the template specialization as copy constructor. But the standard does this because of StoryTeller's explanation. At least, this is a sensible explanation

    – geza
    16 mins ago








  • 1





    @StoryTeller nice catch, no it doesn't : coliru.stacked-crooked.com/a/1de13995fde629be

    – YSC
    15 mins ago



















2















Why is the "non-template" requirement there in the text?




Given it were different and copy constructors could be templates. How could a non-copy constructor not be ambiguous in the presence of a copy constructor template? Consider this:



struct Foo {
// ctor template: clearly useful and necessary
template <typename T>
Foo(const T&) {}

// copy ctor: same signature! can't work
template <typename T>
Foo(const T &) {}
};


Besides, constructing a Foo from an object that is not a Foo can be achieved by either conversion or ordinary construction, but allowing for copy-construction from a non-Foo object changes the notion of copying to copying including conversion. But this can already be implemented with the existing scheme (conversion or non-copy construction).




In this example, here will be printed. So it seems that my template constructor is a copy constructor




The example that you show doesn't invoke copy construction, but an ordinary, implicit construction. If you change the constructor template to



template <typename T>
Foo(const T &) {
// ^^^^^
printf("heren");
}


then Foo b = a; results in the compiler-generated copy constructor being called. Note that the copy ctor generated by the compiler has this signature:



Foo(const Foo&);


This requires adding a const-qualifier to a in Foo b = a;. The original constructor template Foo(T&) in your snippet is a better match, as no const-qualifier is added.






share|improve this answer





















  • 2





    Ah yes! Indeed the whole const vs non-const thing. +1

    – StoryTeller
    15 mins ago



















0














A copy constructor is of the form X(X& ) or (X const&), and will be provided for you by the compiler if you didn't declare one yourself. Non-template comes here probably due to issues if you use template classes.
Let say there is a template class that has a template copy constructor. The problem is that when you instantiate that class using another instance of this class with the same template type, your template copy constructor will not be called.



The issue isn't that your copy constructor template doesn't match. The issue is that the implicit copy constructor is not a function template, and non-templates are preferred to template specializations when it comes to overload resolution.



Source: c++ template copy constructor on template class






share|improve this answer








New contributor




BlackFurry is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















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


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55845896%2fwhy-doesnt-the-standard-consider-a-template-constructor-as-a-copy-constructor%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









    7














    Let's put templates aside for a second. If a class doesn't declare a copy c'tor, an implicitly defaulted one is generated. It may be defined as deleted, but it's defaulted nonetheless.



    A member template is not a member function. Members are instantiated from it only when needed.



    So how can a compiler know from the class definition alone whether or not a specialization with T = Foo will ever be needed? It can't. But it's exactly that on which it needs to base a decision of how to handle a potential need for an implicitly defaulted copy c'tor (AND move c'tor). That becomes messy.



    The easiest approach is to exclude templates. We'll always have some copy c'tor anyway, it will do the correct thingTM by default, and will be favored by overload resolution because it's not instantiated from a template.






    share|improve this answer



















    • 2





      You are always the correct thingTM.

      – Sombrero Chicken
      23 mins ago






    • 1





      What's your opinion on g++ & clang++ printing "here" in the program shown in the Q then?

      – YSC
      21 mins ago






    • 3





      So basically you say that this is because of the rule: "If the class definition does not explicitly declare a copy constructor, a non-explicit one is declared implicitly". And we still expect that the usual implicit copy constructor is defined, no matter of the templated constructor. Yep, this seems the explanation.

      – geza
      21 mins ago






    • 1





      @YSC: it is printed, because the parameter passed is not const, so the template is a better match than the implicit one. But it is confusing (for me) to not call the template specialization as copy constructor. But the standard does this because of StoryTeller's explanation. At least, this is a sensible explanation

      – geza
      16 mins ago








    • 1





      @StoryTeller nice catch, no it doesn't : coliru.stacked-crooked.com/a/1de13995fde629be

      – YSC
      15 mins ago
















    7














    Let's put templates aside for a second. If a class doesn't declare a copy c'tor, an implicitly defaulted one is generated. It may be defined as deleted, but it's defaulted nonetheless.



    A member template is not a member function. Members are instantiated from it only when needed.



    So how can a compiler know from the class definition alone whether or not a specialization with T = Foo will ever be needed? It can't. But it's exactly that on which it needs to base a decision of how to handle a potential need for an implicitly defaulted copy c'tor (AND move c'tor). That becomes messy.



    The easiest approach is to exclude templates. We'll always have some copy c'tor anyway, it will do the correct thingTM by default, and will be favored by overload resolution because it's not instantiated from a template.






    share|improve this answer



















    • 2





      You are always the correct thingTM.

      – Sombrero Chicken
      23 mins ago






    • 1





      What's your opinion on g++ & clang++ printing "here" in the program shown in the Q then?

      – YSC
      21 mins ago






    • 3





      So basically you say that this is because of the rule: "If the class definition does not explicitly declare a copy constructor, a non-explicit one is declared implicitly". And we still expect that the usual implicit copy constructor is defined, no matter of the templated constructor. Yep, this seems the explanation.

      – geza
      21 mins ago






    • 1





      @YSC: it is printed, because the parameter passed is not const, so the template is a better match than the implicit one. But it is confusing (for me) to not call the template specialization as copy constructor. But the standard does this because of StoryTeller's explanation. At least, this is a sensible explanation

      – geza
      16 mins ago








    • 1





      @StoryTeller nice catch, no it doesn't : coliru.stacked-crooked.com/a/1de13995fde629be

      – YSC
      15 mins ago














    7












    7








    7







    Let's put templates aside for a second. If a class doesn't declare a copy c'tor, an implicitly defaulted one is generated. It may be defined as deleted, but it's defaulted nonetheless.



    A member template is not a member function. Members are instantiated from it only when needed.



    So how can a compiler know from the class definition alone whether or not a specialization with T = Foo will ever be needed? It can't. But it's exactly that on which it needs to base a decision of how to handle a potential need for an implicitly defaulted copy c'tor (AND move c'tor). That becomes messy.



    The easiest approach is to exclude templates. We'll always have some copy c'tor anyway, it will do the correct thingTM by default, and will be favored by overload resolution because it's not instantiated from a template.






    share|improve this answer













    Let's put templates aside for a second. If a class doesn't declare a copy c'tor, an implicitly defaulted one is generated. It may be defined as deleted, but it's defaulted nonetheless.



    A member template is not a member function. Members are instantiated from it only when needed.



    So how can a compiler know from the class definition alone whether or not a specialization with T = Foo will ever be needed? It can't. But it's exactly that on which it needs to base a decision of how to handle a potential need for an implicitly defaulted copy c'tor (AND move c'tor). That becomes messy.



    The easiest approach is to exclude templates. We'll always have some copy c'tor anyway, it will do the correct thingTM by default, and will be favored by overload resolution because it's not instantiated from a template.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 25 mins ago









    StoryTellerStoryTeller

    106k14223287




    106k14223287








    • 2





      You are always the correct thingTM.

      – Sombrero Chicken
      23 mins ago






    • 1





      What's your opinion on g++ & clang++ printing "here" in the program shown in the Q then?

      – YSC
      21 mins ago






    • 3





      So basically you say that this is because of the rule: "If the class definition does not explicitly declare a copy constructor, a non-explicit one is declared implicitly". And we still expect that the usual implicit copy constructor is defined, no matter of the templated constructor. Yep, this seems the explanation.

      – geza
      21 mins ago






    • 1





      @YSC: it is printed, because the parameter passed is not const, so the template is a better match than the implicit one. But it is confusing (for me) to not call the template specialization as copy constructor. But the standard does this because of StoryTeller's explanation. At least, this is a sensible explanation

      – geza
      16 mins ago








    • 1





      @StoryTeller nice catch, no it doesn't : coliru.stacked-crooked.com/a/1de13995fde629be

      – YSC
      15 mins ago














    • 2





      You are always the correct thingTM.

      – Sombrero Chicken
      23 mins ago






    • 1





      What's your opinion on g++ & clang++ printing "here" in the program shown in the Q then?

      – YSC
      21 mins ago






    • 3





      So basically you say that this is because of the rule: "If the class definition does not explicitly declare a copy constructor, a non-explicit one is declared implicitly". And we still expect that the usual implicit copy constructor is defined, no matter of the templated constructor. Yep, this seems the explanation.

      – geza
      21 mins ago






    • 1





      @YSC: it is printed, because the parameter passed is not const, so the template is a better match than the implicit one. But it is confusing (for me) to not call the template specialization as copy constructor. But the standard does this because of StoryTeller's explanation. At least, this is a sensible explanation

      – geza
      16 mins ago








    • 1





      @StoryTeller nice catch, no it doesn't : coliru.stacked-crooked.com/a/1de13995fde629be

      – YSC
      15 mins ago








    2




    2





    You are always the correct thingTM.

    – Sombrero Chicken
    23 mins ago





    You are always the correct thingTM.

    – Sombrero Chicken
    23 mins ago




    1




    1





    What's your opinion on g++ & clang++ printing "here" in the program shown in the Q then?

    – YSC
    21 mins ago





    What's your opinion on g++ & clang++ printing "here" in the program shown in the Q then?

    – YSC
    21 mins ago




    3




    3





    So basically you say that this is because of the rule: "If the class definition does not explicitly declare a copy constructor, a non-explicit one is declared implicitly". And we still expect that the usual implicit copy constructor is defined, no matter of the templated constructor. Yep, this seems the explanation.

    – geza
    21 mins ago





    So basically you say that this is because of the rule: "If the class definition does not explicitly declare a copy constructor, a non-explicit one is declared implicitly". And we still expect that the usual implicit copy constructor is defined, no matter of the templated constructor. Yep, this seems the explanation.

    – geza
    21 mins ago




    1




    1





    @YSC: it is printed, because the parameter passed is not const, so the template is a better match than the implicit one. But it is confusing (for me) to not call the template specialization as copy constructor. But the standard does this because of StoryTeller's explanation. At least, this is a sensible explanation

    – geza
    16 mins ago







    @YSC: it is printed, because the parameter passed is not const, so the template is a better match than the implicit one. But it is confusing (for me) to not call the template specialization as copy constructor. But the standard does this because of StoryTeller's explanation. At least, this is a sensible explanation

    – geza
    16 mins ago






    1




    1





    @StoryTeller nice catch, no it doesn't : coliru.stacked-crooked.com/a/1de13995fde629be

    – YSC
    15 mins ago





    @StoryTeller nice catch, no it doesn't : coliru.stacked-crooked.com/a/1de13995fde629be

    – YSC
    15 mins ago













    2















    Why is the "non-template" requirement there in the text?




    Given it were different and copy constructors could be templates. How could a non-copy constructor not be ambiguous in the presence of a copy constructor template? Consider this:



    struct Foo {
    // ctor template: clearly useful and necessary
    template <typename T>
    Foo(const T&) {}

    // copy ctor: same signature! can't work
    template <typename T>
    Foo(const T &) {}
    };


    Besides, constructing a Foo from an object that is not a Foo can be achieved by either conversion or ordinary construction, but allowing for copy-construction from a non-Foo object changes the notion of copying to copying including conversion. But this can already be implemented with the existing scheme (conversion or non-copy construction).




    In this example, here will be printed. So it seems that my template constructor is a copy constructor




    The example that you show doesn't invoke copy construction, but an ordinary, implicit construction. If you change the constructor template to



    template <typename T>
    Foo(const T &) {
    // ^^^^^
    printf("heren");
    }


    then Foo b = a; results in the compiler-generated copy constructor being called. Note that the copy ctor generated by the compiler has this signature:



    Foo(const Foo&);


    This requires adding a const-qualifier to a in Foo b = a;. The original constructor template Foo(T&) in your snippet is a better match, as no const-qualifier is added.






    share|improve this answer





















    • 2





      Ah yes! Indeed the whole const vs non-const thing. +1

      – StoryTeller
      15 mins ago
















    2















    Why is the "non-template" requirement there in the text?




    Given it were different and copy constructors could be templates. How could a non-copy constructor not be ambiguous in the presence of a copy constructor template? Consider this:



    struct Foo {
    // ctor template: clearly useful and necessary
    template <typename T>
    Foo(const T&) {}

    // copy ctor: same signature! can't work
    template <typename T>
    Foo(const T &) {}
    };


    Besides, constructing a Foo from an object that is not a Foo can be achieved by either conversion or ordinary construction, but allowing for copy-construction from a non-Foo object changes the notion of copying to copying including conversion. But this can already be implemented with the existing scheme (conversion or non-copy construction).




    In this example, here will be printed. So it seems that my template constructor is a copy constructor




    The example that you show doesn't invoke copy construction, but an ordinary, implicit construction. If you change the constructor template to



    template <typename T>
    Foo(const T &) {
    // ^^^^^
    printf("heren");
    }


    then Foo b = a; results in the compiler-generated copy constructor being called. Note that the copy ctor generated by the compiler has this signature:



    Foo(const Foo&);


    This requires adding a const-qualifier to a in Foo b = a;. The original constructor template Foo(T&) in your snippet is a better match, as no const-qualifier is added.






    share|improve this answer





















    • 2





      Ah yes! Indeed the whole const vs non-const thing. +1

      – StoryTeller
      15 mins ago














    2












    2








    2








    Why is the "non-template" requirement there in the text?




    Given it were different and copy constructors could be templates. How could a non-copy constructor not be ambiguous in the presence of a copy constructor template? Consider this:



    struct Foo {
    // ctor template: clearly useful and necessary
    template <typename T>
    Foo(const T&) {}

    // copy ctor: same signature! can't work
    template <typename T>
    Foo(const T &) {}
    };


    Besides, constructing a Foo from an object that is not a Foo can be achieved by either conversion or ordinary construction, but allowing for copy-construction from a non-Foo object changes the notion of copying to copying including conversion. But this can already be implemented with the existing scheme (conversion or non-copy construction).




    In this example, here will be printed. So it seems that my template constructor is a copy constructor




    The example that you show doesn't invoke copy construction, but an ordinary, implicit construction. If you change the constructor template to



    template <typename T>
    Foo(const T &) {
    // ^^^^^
    printf("heren");
    }


    then Foo b = a; results in the compiler-generated copy constructor being called. Note that the copy ctor generated by the compiler has this signature:



    Foo(const Foo&);


    This requires adding a const-qualifier to a in Foo b = a;. The original constructor template Foo(T&) in your snippet is a better match, as no const-qualifier is added.






    share|improve this answer
















    Why is the "non-template" requirement there in the text?




    Given it were different and copy constructors could be templates. How could a non-copy constructor not be ambiguous in the presence of a copy constructor template? Consider this:



    struct Foo {
    // ctor template: clearly useful and necessary
    template <typename T>
    Foo(const T&) {}

    // copy ctor: same signature! can't work
    template <typename T>
    Foo(const T &) {}
    };


    Besides, constructing a Foo from an object that is not a Foo can be achieved by either conversion or ordinary construction, but allowing for copy-construction from a non-Foo object changes the notion of copying to copying including conversion. But this can already be implemented with the existing scheme (conversion or non-copy construction).




    In this example, here will be printed. So it seems that my template constructor is a copy constructor




    The example that you show doesn't invoke copy construction, but an ordinary, implicit construction. If you change the constructor template to



    template <typename T>
    Foo(const T &) {
    // ^^^^^
    printf("heren");
    }


    then Foo b = a; results in the compiler-generated copy constructor being called. Note that the copy ctor generated by the compiler has this signature:



    Foo(const Foo&);


    This requires adding a const-qualifier to a in Foo b = a;. The original constructor template Foo(T&) in your snippet is a better match, as no const-qualifier is added.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 12 mins ago

























    answered 25 mins ago









    lubgrlubgr

    16.3k32557




    16.3k32557








    • 2





      Ah yes! Indeed the whole const vs non-const thing. +1

      – StoryTeller
      15 mins ago














    • 2





      Ah yes! Indeed the whole const vs non-const thing. +1

      – StoryTeller
      15 mins ago








    2




    2





    Ah yes! Indeed the whole const vs non-const thing. +1

    – StoryTeller
    15 mins ago





    Ah yes! Indeed the whole const vs non-const thing. +1

    – StoryTeller
    15 mins ago











    0














    A copy constructor is of the form X(X& ) or (X const&), and will be provided for you by the compiler if you didn't declare one yourself. Non-template comes here probably due to issues if you use template classes.
    Let say there is a template class that has a template copy constructor. The problem is that when you instantiate that class using another instance of this class with the same template type, your template copy constructor will not be called.



    The issue isn't that your copy constructor template doesn't match. The issue is that the implicit copy constructor is not a function template, and non-templates are preferred to template specializations when it comes to overload resolution.



    Source: c++ template copy constructor on template class






    share|improve this answer








    New contributor




    BlackFurry is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.

























      0














      A copy constructor is of the form X(X& ) or (X const&), and will be provided for you by the compiler if you didn't declare one yourself. Non-template comes here probably due to issues if you use template classes.
      Let say there is a template class that has a template copy constructor. The problem is that when you instantiate that class using another instance of this class with the same template type, your template copy constructor will not be called.



      The issue isn't that your copy constructor template doesn't match. The issue is that the implicit copy constructor is not a function template, and non-templates are preferred to template specializations when it comes to overload resolution.



      Source: c++ template copy constructor on template class






      share|improve this answer








      New contributor




      BlackFurry is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.























        0












        0








        0







        A copy constructor is of the form X(X& ) or (X const&), and will be provided for you by the compiler if you didn't declare one yourself. Non-template comes here probably due to issues if you use template classes.
        Let say there is a template class that has a template copy constructor. The problem is that when you instantiate that class using another instance of this class with the same template type, your template copy constructor will not be called.



        The issue isn't that your copy constructor template doesn't match. The issue is that the implicit copy constructor is not a function template, and non-templates are preferred to template specializations when it comes to overload resolution.



        Source: c++ template copy constructor on template class






        share|improve this answer








        New contributor




        BlackFurry is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.










        A copy constructor is of the form X(X& ) or (X const&), and will be provided for you by the compiler if you didn't declare one yourself. Non-template comes here probably due to issues if you use template classes.
        Let say there is a template class that has a template copy constructor. The problem is that when you instantiate that class using another instance of this class with the same template type, your template copy constructor will not be called.



        The issue isn't that your copy constructor template doesn't match. The issue is that the implicit copy constructor is not a function template, and non-templates are preferred to template specializations when it comes to overload resolution.



        Source: c++ template copy constructor on template class







        share|improve this answer








        New contributor




        BlackFurry is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        share|improve this answer



        share|improve this answer






        New contributor




        BlackFurry is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        answered 25 mins ago









        BlackFurryBlackFurry

        11




        11




        New contributor




        BlackFurry is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.





        New contributor





        BlackFurry is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






        BlackFurry is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55845896%2fwhy-doesnt-the-standard-consider-a-template-constructor-as-a-copy-constructor%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

            Knooppunt Holsloot

            Altaar (religie)

            Gregoriusmis