Copy/assignment of fundamental types
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
What does the standard say about copy/assignment of fundamental types?
For class types, we have copy constructor, assignment operator, which takes the right hand side as a reference (it must be a reference, otherwise we had infinite recursion):
struct Foo {
Foo(const Foo &);
};
How does this defined for fundamental types?
Look at this example:
const Foo foo;
Foo f = foo;
const int a = 2;
int b = a;
Here, f = foo; odr-uses foo, as copy-constructor takes a reference, right?. If copy of fundamental types had a reference parameter, then b = a would odr-use a as well. Is it the case? If not, how is it handled?
c++ language-lawyer c++17
edited Nov 22 '18 at 10:44
Matthieu Brucher
17.7k52445
asked Nov 22 '18 at 10:41
gezageza
13.9k33180
|
show 6 more comments
What does the standard say about copy/assignment of fundamental types?
For class types, we have copy constructor, assignment operator, which takes the right hand side as a reference (it must be a reference, otherwise we had infinite recursion):
struct Foo {
Foo(const Foo &);
};
How does this defined for fundamental types?
Look at this example:
const Foo foo;
Foo f = foo;
const int a = 2;
int b = a;
Here, f = foo; odr-uses foo, as copy-constructor takes a reference, right?. If copy of fundamental types had a reference parameter, then b = a would odr-use a as well. Is it the case? If not, how is it handled?
c++ language-lawyer c++17
edited Nov 22 '18 at 10:44
Matthieu Brucher
17.7k52445
asked Nov 22 '18 at 10:41
gezageza
13.9k33180
For fundamental types, the implementation (aka compiler) maps the statementb = ato a set of machine instructions that copies the value ofaintobif they are of the same type. There is no actual constructor that is required to be called. So the implementation is free to do that as it likes. Class construction (emitting code to actually call the constructor appropriately) is actually the special case, not handling of fundamental types.
– Peter
Nov 22 '18 at 11:02
@Peter: of course. But this doesn't answer the question whetherais odr-used or not.
– geza
Nov 22 '18 at 11:06
i guess the downvotes are due to not understanding what thelanguage-lawyertag is for, otherwise it would be interesting to know what the downvotes are for
– user463035818
Nov 22 '18 at 11:11
1
The title should be "does assignment of an int odr-use the source" or similar, since that seems to be the question. Also the class example seems irrelevant
– M.M
Nov 22 '18 at 11:11
@M.M: that was the originating problem why I asked this. But then I tried to find what does the standard say about copy/assignment of fundamental types, and I haven't found it. So actually, I'm interested in copy/assignment of fundamental types, not odr-usage (I found odr-usage already, it was easy to find. But I looked through basic.fundamental several times, and haven't found anything - no wonder, as the information is somewhere else).
– geza
Nov 22 '18 at 11:14
|
show 6 more comments
What does the standard say about copy/assignment of fundamental types?
For class types, we have copy constructor, assignment operator, which takes the right hand side as a reference (it must be a reference, otherwise we had infinite recursion):
struct Foo {
Foo(const Foo &);
};
How does this defined for fundamental types?
Look at this example:
const Foo foo;
Foo f = foo;
const int a = 2;
int b = a;
Here, f = foo; odr-uses foo, as copy-constructor takes a reference, right?. If copy of fundamental types had a reference parameter, then b = a would odr-use a as well. Is it the case? If not, how is it handled?
c++ language-lawyer c++17
edited Nov 22 '18 at 10:44
Matthieu Brucher
17.7k52445
asked Nov 22 '18 at 10:41
gezageza
13.9k33180
What does the standard say about copy/assignment of fundamental types?
For class types, we have copy constructor, assignment operator, which takes the right hand side as a reference (it must be a reference, otherwise we had infinite recursion):
struct Foo {
Foo(const Foo &);
};
How does this defined for fundamental types?
Look at this example:
const Foo foo;
Foo f = foo;
const int a = 2;
int b = a;
Here, f = foo; odr-uses foo, as copy-constructor takes a reference, right?. If copy of fundamental types had a reference parameter, then b = a would odr-use a as well. Is it the case? If not, how is it handled?
c++ language-lawyer c++17
c++ language-lawyer c++17
edited Nov 22 '18 at 10:44
Matthieu Brucher
17.7k52445
asked Nov 22 '18 at 10:41
gezageza
13.9k33180
edited Nov 22 '18 at 10:44
Matthieu Brucher
17.7k52445
asked Nov 22 '18 at 10:41
gezageza
13.9k33180
edited Nov 22 '18 at 10:44
Matthieu Brucher
17.7k52445
edited Nov 22 '18 at 10:44
Matthieu Brucher
17.7k52445
edited Nov 22 '18 at 10:44
Matthieu Brucher
17.7k52445
17.7k52445
asked Nov 22 '18 at 10:41
gezageza
13.9k33180
asked Nov 22 '18 at 10:41
gezageza
13.9k33180
asked Nov 22 '18 at 10:41
gezageza
13.9k33180
13.9k33180
For fundamental types, the implementation (aka compiler) maps the statementb = ato a set of machine instructions that copies the value ofaintobif they are of the same type. There is no actual constructor that is required to be called. So the implementation is free to do that as it likes. Class construction (emitting code to actually call the constructor appropriately) is actually the special case, not handling of fundamental types.
– Peter
Nov 22 '18 at 11:02
@Peter: of course. But this doesn't answer the question whetherais odr-used or not.
– geza
Nov 22 '18 at 11:06
i guess the downvotes are due to not understanding what thelanguage-lawyertag is for, otherwise it would be interesting to know what the downvotes are for
– user463035818
Nov 22 '18 at 11:11
1
The title should be "does assignment of an int odr-use the source" or similar, since that seems to be the question. Also the class example seems irrelevant
– M.M
Nov 22 '18 at 11:11
@M.M: that was the originating problem why I asked this. But then I tried to find what does the standard say about copy/assignment of fundamental types, and I haven't found it. So actually, I'm interested in copy/assignment of fundamental types, not odr-usage (I found odr-usage already, it was easy to find. But I looked through basic.fundamental several times, and haven't found anything - no wonder, as the information is somewhere else).
– geza
Nov 22 '18 at 11:14
|
show 6 more comments
For fundamental types, the implementation (aka compiler) maps the statementb = ato a set of machine instructions that copies the value ofaintobif they are of the same type. There is no actual constructor that is required to be called. So the implementation is free to do that as it likes. Class construction (emitting code to actually call the constructor appropriately) is actually the special case, not handling of fundamental types.
– Peter
Nov 22 '18 at 11:02
@Peter: of course. But this doesn't answer the question whetherais odr-used or not.
– geza
Nov 22 '18 at 11:06
i guess the downvotes are due to not understanding what thelanguage-lawyertag is for, otherwise it would be interesting to know what the downvotes are for
– user463035818
Nov 22 '18 at 11:11
1
The title should be "does assignment of an int odr-use the source" or similar, since that seems to be the question. Also the class example seems irrelevant
– M.M
Nov 22 '18 at 11:11
@M.M: that was the originating problem why I asked this. But then I tried to find what does the standard say about copy/assignment of fundamental types, and I haven't found it. So actually, I'm interested in copy/assignment of fundamental types, not odr-usage (I found odr-usage already, it was easy to find. But I looked through basic.fundamental several times, and haven't found anything - no wonder, as the information is somewhere else).
– geza
Nov 22 '18 at 11:14
For fundamental types, the implementation (aka compiler) maps the statement
b = a to a set of machine instructions that copies the value of a into b if they are of the same type. There is no actual constructor that is required to be called. So the implementation is free to do that as it likes. Class construction (emitting code to actually call the constructor appropriately) is actually the special case, not handling of fundamental types.– Peter
Nov 22 '18 at 11:02
For fundamental types, the implementation (aka compiler) maps the statement
b = a to a set of machine instructions that copies the value of a into b if they are of the same type. There is no actual constructor that is required to be called. So the implementation is free to do that as it likes. Class construction (emitting code to actually call the constructor appropriately) is actually the special case, not handling of fundamental types.– Peter
Nov 22 '18 at 11:02
@Peter: of course. But this doesn't answer the question whether
a is odr-used or not.– geza
Nov 22 '18 at 11:06
@Peter: of course. But this doesn't answer the question whether
a is odr-used or not.– geza
Nov 22 '18 at 11:06
i guess the downvotes are due to not understanding what the
language-lawyer tag is for, otherwise it would be interesting to know what the downvotes are for– user463035818
Nov 22 '18 at 11:11
i guess the downvotes are due to not understanding what the
language-lawyer tag is for, otherwise it would be interesting to know what the downvotes are for– user463035818
Nov 22 '18 at 11:11
1
1
The title should be "does assignment of an int odr-use the source" or similar, since that seems to be the question. Also the class example seems irrelevant
– M.M
Nov 22 '18 at 11:11
The title should be "does assignment of an int odr-use the source" or similar, since that seems to be the question. Also the class example seems irrelevant
– M.M
Nov 22 '18 at 11:11
@M.M: that was the originating problem why I asked this. But then I tried to find what does the standard say about copy/assignment of fundamental types, and I haven't found it. So actually, I'm interested in copy/assignment of fundamental types, not odr-usage (I found odr-usage already, it was easy to find. But I looked through basic.fundamental several times, and haven't found anything - no wonder, as the information is somewhere else).
– geza
Nov 22 '18 at 11:14
@M.M: that was the originating problem why I asked this. But then I tried to find what does the standard say about copy/assignment of fundamental types, and I haven't found it. So actually, I'm interested in copy/assignment of fundamental types, not odr-usage (I found odr-usage already, it was easy to find. But I looked through basic.fundamental several times, and haven't found anything - no wonder, as the information is somewhere else).
– geza
Nov 22 '18 at 11:14
|
show 6 more comments
1 Answer
1
active
oldest
votes
We can trace it. Starting at [dcl.init].
(17.8) - Otherwise, the initial value of the object being initialized
is the (possibly converted) value of the initializer expression.
Standard conversions will be used, if necessary, to convert the
initializer expression to the cv-unqualified version of the
destination type; no user-defined conversions are considered. If the
conversion cannot be done, the initialization is ill-formed. When
initializing a bit-field with a value that it cannot represent, the
resulting value of the bit-field is implementation-defined.
The standard conversion in this case would be the lvalue-to-rvalue conversion on a. But that doesn't odr-use a. For we see in [basic.def.odr]
2 A variable x whose name appears as a potentially-evaluated expression
ex is odr-used by ex unless applying the lvalue-to-rvalue conversion
to x yields a constant expression that does not invoke any non-trivial
functions and, if x is an object, ex is an element of the set of
potential results of an expression e, where either the
lvalue-to-rvalue conversion is applied to e, or e is a discarded-value
expression.
a is a constant expression and substitution of a for x and ex above demonstrates it holds the other half of the condition, so it's not odr-used.
answered Nov 22 '18 at 11:01
StoryTellerStoryTeller
106k13222285
1
@YSC -ais a constant expression.
– StoryTeller
Nov 22 '18 at 11:05
As for[dcl.init], the OP asked to for an explanation of how this initialization works. So it made sense to me to start there.
– StoryTeller
Nov 22 '18 at 11:06
@StoryTeller I overlooked the rule... but... does it mean I can define aconst int awith different values in different translation units? I know they would have internal linkage, but stilll I'm surprised.
– YSC
Nov 22 '18 at 11:08
@YSC - You can. It's what makes it usable as an (superior) alternative to macros for constants.
– StoryTeller
Nov 22 '18 at 11:09
1
@phön - Such an object would be a constant expression too, so an l-to-r conversion alone won't odr-use it, I think.
– StoryTeller
Nov 22 '18 at 12:45
|
show 6 more comments
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%2f53429108%2fcopy-assignment-of-fundamental-types%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
We can trace it. Starting at [dcl.init].
(17.8) - Otherwise, the initial value of the object being initialized
is the (possibly converted) value of the initializer expression.
Standard conversions will be used, if necessary, to convert the
initializer expression to the cv-unqualified version of the
destination type; no user-defined conversions are considered. If the
conversion cannot be done, the initialization is ill-formed. When
initializing a bit-field with a value that it cannot represent, the
resulting value of the bit-field is implementation-defined.
The standard conversion in this case would be the lvalue-to-rvalue conversion on a. But that doesn't odr-use a. For we see in [basic.def.odr]
2 A variable x whose name appears as a potentially-evaluated expression
ex is odr-used by ex unless applying the lvalue-to-rvalue conversion
to x yields a constant expression that does not invoke any non-trivial
functions and, if x is an object, ex is an element of the set of
potential results of an expression e, where either the
lvalue-to-rvalue conversion is applied to e, or e is a discarded-value
expression.
a is a constant expression and substitution of a for x and ex above demonstrates it holds the other half of the condition, so it's not odr-used.
answered Nov 22 '18 at 11:01
StoryTellerStoryTeller
106k13222285
1
@YSC -ais a constant expression.
– StoryTeller
Nov 22 '18 at 11:05
As for[dcl.init], the OP asked to for an explanation of how this initialization works. So it made sense to me to start there.
– StoryTeller
Nov 22 '18 at 11:06
@StoryTeller I overlooked the rule... but... does it mean I can define aconst int awith different values in different translation units? I know they would have internal linkage, but stilll I'm surprised.
– YSC
Nov 22 '18 at 11:08
@YSC - You can. It's what makes it usable as an (superior) alternative to macros for constants.
– StoryTeller
Nov 22 '18 at 11:09
1
@phön - Such an object would be a constant expression too, so an l-to-r conversion alone won't odr-use it, I think.
– StoryTeller
Nov 22 '18 at 12:45
|
show 6 more comments
We can trace it. Starting at [dcl.init].
(17.8) - Otherwise, the initial value of the object being initialized
is the (possibly converted) value of the initializer expression.
Standard conversions will be used, if necessary, to convert the
initializer expression to the cv-unqualified version of the
destination type; no user-defined conversions are considered. If the
conversion cannot be done, the initialization is ill-formed. When
initializing a bit-field with a value that it cannot represent, the
resulting value of the bit-field is implementation-defined.
The standard conversion in this case would be the lvalue-to-rvalue conversion on a. But that doesn't odr-use a. For we see in [basic.def.odr]
2 A variable x whose name appears as a potentially-evaluated expression
ex is odr-used by ex unless applying the lvalue-to-rvalue conversion
to x yields a constant expression that does not invoke any non-trivial
functions and, if x is an object, ex is an element of the set of
potential results of an expression e, where either the
lvalue-to-rvalue conversion is applied to e, or e is a discarded-value
expression.
a is a constant expression and substitution of a for x and ex above demonstrates it holds the other half of the condition, so it's not odr-used.
answered Nov 22 '18 at 11:01
StoryTellerStoryTeller
106k13222285
1
@YSC -ais a constant expression.
– StoryTeller
Nov 22 '18 at 11:05
As for[dcl.init], the OP asked to for an explanation of how this initialization works. So it made sense to me to start there.
– StoryTeller
Nov 22 '18 at 11:06
@StoryTeller I overlooked the rule... but... does it mean I can define aconst int awith different values in different translation units? I know they would have internal linkage, but stilll I'm surprised.
– YSC
Nov 22 '18 at 11:08
@YSC - You can. It's what makes it usable as an (superior) alternative to macros for constants.
– StoryTeller
Nov 22 '18 at 11:09
1
@phön - Such an object would be a constant expression too, so an l-to-r conversion alone won't odr-use it, I think.
– StoryTeller
Nov 22 '18 at 12:45
|
show 6 more comments
We can trace it. Starting at [dcl.init].
(17.8) - Otherwise, the initial value of the object being initialized
is the (possibly converted) value of the initializer expression.
Standard conversions will be used, if necessary, to convert the
initializer expression to the cv-unqualified version of the
destination type; no user-defined conversions are considered. If the
conversion cannot be done, the initialization is ill-formed. When
initializing a bit-field with a value that it cannot represent, the
resulting value of the bit-field is implementation-defined.
The standard conversion in this case would be the lvalue-to-rvalue conversion on a. But that doesn't odr-use a. For we see in [basic.def.odr]
2 A variable x whose name appears as a potentially-evaluated expression
ex is odr-used by ex unless applying the lvalue-to-rvalue conversion
to x yields a constant expression that does not invoke any non-trivial
functions and, if x is an object, ex is an element of the set of
potential results of an expression e, where either the
lvalue-to-rvalue conversion is applied to e, or e is a discarded-value
expression.
a is a constant expression and substitution of a for x and ex above demonstrates it holds the other half of the condition, so it's not odr-used.
answered Nov 22 '18 at 11:01
StoryTellerStoryTeller
106k13222285
We can trace it. Starting at [dcl.init].
(17.8) - Otherwise, the initial value of the object being initialized
is the (possibly converted) value of the initializer expression.
Standard conversions will be used, if necessary, to convert the
initializer expression to the cv-unqualified version of the
destination type; no user-defined conversions are considered. If the
conversion cannot be done, the initialization is ill-formed. When
initializing a bit-field with a value that it cannot represent, the
resulting value of the bit-field is implementation-defined.
The standard conversion in this case would be the lvalue-to-rvalue conversion on a. But that doesn't odr-use a. For we see in [basic.def.odr]
2 A variable x whose name appears as a potentially-evaluated expression
ex is odr-used by ex unless applying the lvalue-to-rvalue conversion
to x yields a constant expression that does not invoke any non-trivial
functions and, if x is an object, ex is an element of the set of
potential results of an expression e, where either the
lvalue-to-rvalue conversion is applied to e, or e is a discarded-value
expression.
a is a constant expression and substitution of a for x and ex above demonstrates it holds the other half of the condition, so it's not odr-used.
answered Nov 22 '18 at 11:01
StoryTellerStoryTeller
106k13222285
edited Nov 22 '18 at 11:04
answered Nov 22 '18 at 11:01
StoryTellerStoryTeller
106k13222285
answered Nov 22 '18 at 11:01
StoryTellerStoryTeller
106k13222285
answered Nov 22 '18 at 11:01
StoryTellerStoryTeller
106k13222285
106k13222285
1
@YSC -ais a constant expression.
– StoryTeller
Nov 22 '18 at 11:05
As for[dcl.init], the OP asked to for an explanation of how this initialization works. So it made sense to me to start there.
– StoryTeller
Nov 22 '18 at 11:06
@StoryTeller I overlooked the rule... but... does it mean I can define aconst int awith different values in different translation units? I know they would have internal linkage, but stilll I'm surprised.
– YSC
Nov 22 '18 at 11:08
@YSC - You can. It's what makes it usable as an (superior) alternative to macros for constants.
– StoryTeller
Nov 22 '18 at 11:09
1
@phön - Such an object would be a constant expression too, so an l-to-r conversion alone won't odr-use it, I think.
– StoryTeller
Nov 22 '18 at 12:45
|
show 6 more comments
1
@YSC -ais a constant expression.
– StoryTeller
Nov 22 '18 at 11:05
As for[dcl.init], the OP asked to for an explanation of how this initialization works. So it made sense to me to start there.
– StoryTeller
Nov 22 '18 at 11:06
@StoryTeller I overlooked the rule... but... does it mean I can define aconst int awith different values in different translation units? I know they would have internal linkage, but stilll I'm surprised.
– YSC
Nov 22 '18 at 11:08
@YSC - You can. It's what makes it usable as an (superior) alternative to macros for constants.
– StoryTeller
Nov 22 '18 at 11:09
1
@phön - Such an object would be a constant expression too, so an l-to-r conversion alone won't odr-use it, I think.
– StoryTeller
Nov 22 '18 at 12:45
1
1
@YSC -
a is a constant expression.– StoryTeller
Nov 22 '18 at 11:05
@YSC -
a is a constant expression.– StoryTeller
Nov 22 '18 at 11:05
As for
[dcl.init], the OP asked to for an explanation of how this initialization works. So it made sense to me to start there.– StoryTeller
Nov 22 '18 at 11:06
As for
[dcl.init], the OP asked to for an explanation of how this initialization works. So it made sense to me to start there.– StoryTeller
Nov 22 '18 at 11:06
@StoryTeller I overlooked the rule... but... does it mean I can define a
const int a with different values in different translation units? I know they would have internal linkage, but stilll I'm surprised.– YSC
Nov 22 '18 at 11:08
@StoryTeller I overlooked the rule... but... does it mean I can define a
const int a with different values in different translation units? I know they would have internal linkage, but stilll I'm surprised.– YSC
Nov 22 '18 at 11:08
@YSC - You can. It's what makes it usable as an (superior) alternative to macros for constants.
– StoryTeller
Nov 22 '18 at 11:09
@YSC - You can. It's what makes it usable as an (superior) alternative to macros for constants.
– StoryTeller
Nov 22 '18 at 11:09
1
1
@phön - Such an object would be a constant expression too, so an l-to-r conversion alone won't odr-use it, I think.
– StoryTeller
Nov 22 '18 at 12:45
@phön - Such an object would be a constant expression too, so an l-to-r conversion alone won't odr-use it, I think.
– StoryTeller
Nov 22 '18 at 12:45
|
show 6 more comments
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%2f53429108%2fcopy-assignment-of-fundamental-types%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
For fundamental types, the implementation (aka compiler) maps the statement
b = ato a set of machine instructions that copies the value ofaintobif they are of the same type. There is no actual constructor that is required to be called. So the implementation is free to do that as it likes. Class construction (emitting code to actually call the constructor appropriately) is actually the special case, not handling of fundamental types.– Peter
Nov 22 '18 at 11:02
@Peter: of course. But this doesn't answer the question whether
ais odr-used or not.– geza
Nov 22 '18 at 11:06
i guess the downvotes are due to not understanding what the
language-lawyertag is for, otherwise it would be interesting to know what the downvotes are for– user463035818
Nov 22 '18 at 11:11
1
The title should be "does assignment of an int odr-use the source" or similar, since that seems to be the question. Also the class example seems irrelevant
– M.M
Nov 22 '18 at 11:11
@M.M: that was the originating problem why I asked this. But then I tried to find what does the standard say about copy/assignment of fundamental types, and I haven't found it. So actually, I'm interested in copy/assignment of fundamental types, not odr-usage (I found odr-usage already, it was easy to find. But I looked through basic.fundamental several times, and haven't found anything - no wonder, as the information is somewhere else).
– geza
Nov 22 '18 at 11:14