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;
}
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
|
show 2 more comments
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
Note: I'm note sureFoo b = a
instantiates and callsFoo::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 youFoo c = std::move(a);
?
– Caleth
32 mins ago
see stackoverflow.com/a/24832212/3370124
– Richard Critten
30 mins ago
|
show 2 more comments
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
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
c++ language-lawyer
edited 41 mins ago
πάντα ῥεῖ
74.4k1077145
74.4k1077145
asked 44 mins ago
gezageza
14.1k33282
14.1k33282
Note: I'm note sureFoo b = a
instantiates and callsFoo::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 youFoo c = std::move(a);
?
– Caleth
32 mins ago
see stackoverflow.com/a/24832212/3370124
– Richard Critten
30 mins ago
|
show 2 more comments
Note: I'm note sureFoo b = a
instantiates and callsFoo::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 youFoo 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
|
show 2 more comments
3 Answers
3
active
oldest
votes
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.
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
|
show 3 more comments
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.
2
Ah yes! Indeed the whole const vs non-const thing. +1
– StoryTeller
15 mins ago
add a comment |
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
New contributor
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%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
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.
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
|
show 3 more comments
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.
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
|
show 3 more comments
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.
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.
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
|
show 3 more comments
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
|
show 3 more comments
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.
2
Ah yes! Indeed the whole const vs non-const thing. +1
– StoryTeller
15 mins ago
add a comment |
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.
2
Ah yes! Indeed the whole const vs non-const thing. +1
– StoryTeller
15 mins ago
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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
New contributor
add a comment |
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
New contributor
add a comment |
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
New contributor
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
New contributor
New contributor
answered 25 mins ago
BlackFurryBlackFurry
11
11
New contributor
New contributor
add a comment |
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%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
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
Note: I'm note sure
Foo b = a
instantiates and callsFoo::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