How can a conforming C++ implementation indicate that it doesn't know the current date and time?
Some C++ implementations (for instance, battery-powered embedded devices) may have no use or no way for tracking the current date and time.
The C standard specifically allows for such implementations. To quote from ISO/IEC 9899:1999 7.23.2.4 (emphasis mine):
The time function returns the implementation’s best approximation to the current
calendar time. The value (time_t)(-1) is returned if the calendar time is not
available.
C++11 introduced the chrono library and the std::chrono::system_clock::now() function for getting the wall clock time from the system-wide realtime clock. The function is declared as noexcept, so it cannot throw any exception to indicate unavailability nor does it allow returning any special value (like -1 in the case of C).
But with C++11, C++14 and C++17 there was still a loophole. The standard didn't specify the clock's epoch, so a conforming implementation could set the epoch to the point in time when it was powered on (or the program was started) and still satisfy the requirements of the standard.
The current draft of C++20 will close that loophole and require system_clock to use Unix time. In other words, a C++ implementation that doesn't know the current time is non-conforming.
Is this an oversight by the standards committee? How can a conforming C++ implementation indicate that it doesn't know the current date and time?
(Note that in other parts of the standard this problem is solved. For instance, an implementation may set the __TIME__ and __DATE__ macros to an implementation-defined value if the real time and date is not available.)
c++ time language-lawyer chrono c++20
edited 1 hour ago
user10605163
2,783524
asked 1 hour ago
Norask
443
New contributor
Norask is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
Some C++ implementations (for instance, battery-powered embedded devices) may have no use or no way for tracking the current date and time.
The C standard specifically allows for such implementations. To quote from ISO/IEC 9899:1999 7.23.2.4 (emphasis mine):
The time function returns the implementation’s best approximation to the current
calendar time. The value (time_t)(-1) is returned if the calendar time is not
available.
C++11 introduced the chrono library and the std::chrono::system_clock::now() function for getting the wall clock time from the system-wide realtime clock. The function is declared as noexcept, so it cannot throw any exception to indicate unavailability nor does it allow returning any special value (like -1 in the case of C).
But with C++11, C++14 and C++17 there was still a loophole. The standard didn't specify the clock's epoch, so a conforming implementation could set the epoch to the point in time when it was powered on (or the program was started) and still satisfy the requirements of the standard.
The current draft of C++20 will close that loophole and require system_clock to use Unix time. In other words, a C++ implementation that doesn't know the current time is non-conforming.
Is this an oversight by the standards committee? How can a conforming C++ implementation indicate that it doesn't know the current date and time?
(Note that in other parts of the standard this problem is solved. For instance, an implementation may set the __TIME__ and __DATE__ macros to an implementation-defined value if the real time and date is not available.)
c++ time language-lawyer chrono c++20
edited 1 hour ago
user10605163
2,783524
asked 1 hour ago
Norask
443
New contributor
Norask is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Welp. Looks like a C++ implementation that cannot provide the current meatspace time would be non-conforming. That's not really a showstopper. It is not entirely unprecedented for special-purpose C++ implementation not to support this thing, or that thing. I wouldn't be surprised if a C++ implementation that's targeting some embedded platform doesn't have astd::thread, for example.
– Sam Varshavchik
1 hour ago
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
1 hour ago
Perhaps a compiler targeted at an architecture that does not support time should not implementsystem_clockat all?
– AndyG
52 mins ago
@StoryTeller Both. Freestanding implementations, however, could get around this by not providing the 'chrono' library at all (which would also exclude all other clocks).
– Norask
48 mins ago
add a comment |
Some C++ implementations (for instance, battery-powered embedded devices) may have no use or no way for tracking the current date and time.
The C standard specifically allows for such implementations. To quote from ISO/IEC 9899:1999 7.23.2.4 (emphasis mine):
The time function returns the implementation’s best approximation to the current
calendar time. The value (time_t)(-1) is returned if the calendar time is not
available.
C++11 introduced the chrono library and the std::chrono::system_clock::now() function for getting the wall clock time from the system-wide realtime clock. The function is declared as noexcept, so it cannot throw any exception to indicate unavailability nor does it allow returning any special value (like -1 in the case of C).
But with C++11, C++14 and C++17 there was still a loophole. The standard didn't specify the clock's epoch, so a conforming implementation could set the epoch to the point in time when it was powered on (or the program was started) and still satisfy the requirements of the standard.
The current draft of C++20 will close that loophole and require system_clock to use Unix time. In other words, a C++ implementation that doesn't know the current time is non-conforming.
Is this an oversight by the standards committee? How can a conforming C++ implementation indicate that it doesn't know the current date and time?
(Note that in other parts of the standard this problem is solved. For instance, an implementation may set the __TIME__ and __DATE__ macros to an implementation-defined value if the real time and date is not available.)
c++ time language-lawyer chrono c++20
edited 1 hour ago
user10605163
2,783524
asked 1 hour ago
Norask
443
New contributor
Norask is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Some C++ implementations (for instance, battery-powered embedded devices) may have no use or no way for tracking the current date and time.
The C standard specifically allows for such implementations. To quote from ISO/IEC 9899:1999 7.23.2.4 (emphasis mine):
The time function returns the implementation’s best approximation to the current
calendar time. The value (time_t)(-1) is returned if the calendar time is not
available.
C++11 introduced the chrono library and the std::chrono::system_clock::now() function for getting the wall clock time from the system-wide realtime clock. The function is declared as noexcept, so it cannot throw any exception to indicate unavailability nor does it allow returning any special value (like -1 in the case of C).
But with C++11, C++14 and C++17 there was still a loophole. The standard didn't specify the clock's epoch, so a conforming implementation could set the epoch to the point in time when it was powered on (or the program was started) and still satisfy the requirements of the standard.
The current draft of C++20 will close that loophole and require system_clock to use Unix time. In other words, a C++ implementation that doesn't know the current time is non-conforming.
Is this an oversight by the standards committee? How can a conforming C++ implementation indicate that it doesn't know the current date and time?
(Note that in other parts of the standard this problem is solved. For instance, an implementation may set the __TIME__ and __DATE__ macros to an implementation-defined value if the real time and date is not available.)
c++ time language-lawyer chrono c++20
c++ time language-lawyer chrono c++20
edited 1 hour ago
user10605163
2,783524
asked 1 hour ago
Norask
443
New contributor
Norask is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 1 hour ago
user10605163
2,783524
asked 1 hour ago
Norask
443
New contributor
Norask is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 1 hour ago
user10605163
2,783524
edited 1 hour ago
user10605163
2,783524
edited 1 hour ago
user10605163
2,783524
2,783524
asked 1 hour ago
Norask
443
New contributor
Norask is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
Norask
443
asked 1 hour ago
Norask
443
443
New contributor
Norask is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Norask is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Norask is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
Welp. Looks like a C++ implementation that cannot provide the current meatspace time would be non-conforming. That's not really a showstopper. It is not entirely unprecedented for special-purpose C++ implementation not to support this thing, or that thing. I wouldn't be surprised if a C++ implementation that's targeting some embedded platform doesn't have astd::thread, for example.
– Sam Varshavchik
1 hour ago
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
1 hour ago
Perhaps a compiler targeted at an architecture that does not support time should not implementsystem_clockat all?
– AndyG
52 mins ago
@StoryTeller Both. Freestanding implementations, however, could get around this by not providing the 'chrono' library at all (which would also exclude all other clocks).
– Norask
48 mins ago
add a comment |
1
Welp. Looks like a C++ implementation that cannot provide the current meatspace time would be non-conforming. That's not really a showstopper. It is not entirely unprecedented for special-purpose C++ implementation not to support this thing, or that thing. I wouldn't be surprised if a C++ implementation that's targeting some embedded platform doesn't have astd::thread, for example.
– Sam Varshavchik
1 hour ago
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
1 hour ago
Perhaps a compiler targeted at an architecture that does not support time should not implementsystem_clockat all?
– AndyG
52 mins ago
@StoryTeller Both. Freestanding implementations, however, could get around this by not providing the 'chrono' library at all (which would also exclude all other clocks).
– Norask
48 mins ago
1
1
Welp. Looks like a C++ implementation that cannot provide the current meatspace time would be non-conforming. That's not really a showstopper. It is not entirely unprecedented for special-purpose C++ implementation not to support this thing, or that thing. I wouldn't be surprised if a C++ implementation that's targeting some embedded platform doesn't have a
std::thread, for example.– Sam Varshavchik
1 hour ago
Welp. Looks like a C++ implementation that cannot provide the current meatspace time would be non-conforming. That's not really a showstopper. It is not entirely unprecedented for special-purpose C++ implementation not to support this thing, or that thing. I wouldn't be surprised if a C++ implementation that's targeting some embedded platform doesn't have a
std::thread, for example.– Sam Varshavchik
1 hour ago
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
1 hour ago
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
1 hour ago
Perhaps a compiler targeted at an architecture that does not support time should not implement
system_clock at all?– AndyG
52 mins ago
Perhaps a compiler targeted at an architecture that does not support time should not implement
system_clock at all?– AndyG
52 mins ago
@StoryTeller Both. Freestanding implementations, however, could get around this by not providing the 'chrono' library at all (which would also exclude all other clocks).
– Norask
48 mins ago
@StoryTeller Both. Freestanding implementations, however, could get around this by not providing the 'chrono' library at all (which would also exclude all other clocks).
– Norask
48 mins ago
add a comment |
1 Answer
1
active
oldest
votes
There is a distinction to be made between knowing the time, and knowing the correct time.
If such a device is turned on, it may freely assume that its CPU cycle counter (or whatever powers steady_clock) represents the number of cycles since UNIX time. That is, it can assume that it was powered on at the moment of the UNIX epoch. That would be a valid implementation of system_clock. That time will likely not be correct in some absolute sense, but it will be a conforming C++20 implementation.
The standard simply requires system_clock's epoch to be UNIX time (or more specifically, we can all assume that it is UNIX time). That doesn't mean the tick count retrieved for the clock is guaranteed to be the globally accurate current time. After all, the user can technically change the current time, which is meant to be reflected in system_clock (which is why it is not required to be a steady clock).
As such, you could never assume that system_clock accurately represented the current time; it only represents what the operating environment thinks is the current time. So there is no way for chrono to explain that the current time is or is not "correct" in some sense.
system_clock is basically meant to provide whatever is the closest to the correct time-of-day that the system can provide or understand. If the best the system can do is to assume that the device was turned on at the UNIX epoch, then that's what you get.
Furthermore, since system_clock (and all of <chrono> for that matter) is not on the list of freestanding requirements, C++ implementations for such devices could be freestanding implementations. And therefore they choose not to implement system_clock (or all of <chrono>) at all.
answered 54 mins ago
Nicol Bolas
282k33466641
Interesting. So it could be the correct time, the incorrect time or even some fixed dummy time the device is set to when powered on that in no way correlates to any real time and it would still be conforming.
– Norask
28 mins ago
If a freestanding implementation implements everything fromchronoexceptsystem_clockit would still be conforming, right? There is no requirement in the standard that if a header is provided that it has to be provided fully, right?
– Norask
10 mins ago
1
@Norask:<chrono>is a header, not a library. There is only one standard library. And yes, for freestanding implementations, not all parts of a header have to be provided. That's why I said, "And therefore they choose not to implementsystem_clock(or all of<chrono>) at all.".
– Nicol Bolas
8 mins ago
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
});
}
});
Norask is a new contributor. Be nice, and check out our Code of Conduct.
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%2f53997248%2fhow-can-a-conforming-c-implementation-indicate-that-it-doesnt-know-the-curren%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
There is a distinction to be made between knowing the time, and knowing the correct time.
If such a device is turned on, it may freely assume that its CPU cycle counter (or whatever powers steady_clock) represents the number of cycles since UNIX time. That is, it can assume that it was powered on at the moment of the UNIX epoch. That would be a valid implementation of system_clock. That time will likely not be correct in some absolute sense, but it will be a conforming C++20 implementation.
The standard simply requires system_clock's epoch to be UNIX time (or more specifically, we can all assume that it is UNIX time). That doesn't mean the tick count retrieved for the clock is guaranteed to be the globally accurate current time. After all, the user can technically change the current time, which is meant to be reflected in system_clock (which is why it is not required to be a steady clock).
As such, you could never assume that system_clock accurately represented the current time; it only represents what the operating environment thinks is the current time. So there is no way for chrono to explain that the current time is or is not "correct" in some sense.
system_clock is basically meant to provide whatever is the closest to the correct time-of-day that the system can provide or understand. If the best the system can do is to assume that the device was turned on at the UNIX epoch, then that's what you get.
Furthermore, since system_clock (and all of <chrono> for that matter) is not on the list of freestanding requirements, C++ implementations for such devices could be freestanding implementations. And therefore they choose not to implement system_clock (or all of <chrono>) at all.
answered 54 mins ago
Nicol Bolas
282k33466641
Interesting. So it could be the correct time, the incorrect time or even some fixed dummy time the device is set to when powered on that in no way correlates to any real time and it would still be conforming.
– Norask
28 mins ago
If a freestanding implementation implements everything fromchronoexceptsystem_clockit would still be conforming, right? There is no requirement in the standard that if a header is provided that it has to be provided fully, right?
– Norask
10 mins ago
1
@Norask:<chrono>is a header, not a library. There is only one standard library. And yes, for freestanding implementations, not all parts of a header have to be provided. That's why I said, "And therefore they choose not to implementsystem_clock(or all of<chrono>) at all.".
– Nicol Bolas
8 mins ago
add a comment |
There is a distinction to be made between knowing the time, and knowing the correct time.
If such a device is turned on, it may freely assume that its CPU cycle counter (or whatever powers steady_clock) represents the number of cycles since UNIX time. That is, it can assume that it was powered on at the moment of the UNIX epoch. That would be a valid implementation of system_clock. That time will likely not be correct in some absolute sense, but it will be a conforming C++20 implementation.
The standard simply requires system_clock's epoch to be UNIX time (or more specifically, we can all assume that it is UNIX time). That doesn't mean the tick count retrieved for the clock is guaranteed to be the globally accurate current time. After all, the user can technically change the current time, which is meant to be reflected in system_clock (which is why it is not required to be a steady clock).
As such, you could never assume that system_clock accurately represented the current time; it only represents what the operating environment thinks is the current time. So there is no way for chrono to explain that the current time is or is not "correct" in some sense.
system_clock is basically meant to provide whatever is the closest to the correct time-of-day that the system can provide or understand. If the best the system can do is to assume that the device was turned on at the UNIX epoch, then that's what you get.
Furthermore, since system_clock (and all of <chrono> for that matter) is not on the list of freestanding requirements, C++ implementations for such devices could be freestanding implementations. And therefore they choose not to implement system_clock (or all of <chrono>) at all.
answered 54 mins ago
Nicol Bolas
282k33466641
Interesting. So it could be the correct time, the incorrect time or even some fixed dummy time the device is set to when powered on that in no way correlates to any real time and it would still be conforming.
– Norask
28 mins ago
If a freestanding implementation implements everything fromchronoexceptsystem_clockit would still be conforming, right? There is no requirement in the standard that if a header is provided that it has to be provided fully, right?
– Norask
10 mins ago
1
@Norask:<chrono>is a header, not a library. There is only one standard library. And yes, for freestanding implementations, not all parts of a header have to be provided. That's why I said, "And therefore they choose not to implementsystem_clock(or all of<chrono>) at all.".
– Nicol Bolas
8 mins ago
add a comment |
There is a distinction to be made between knowing the time, and knowing the correct time.
If such a device is turned on, it may freely assume that its CPU cycle counter (or whatever powers steady_clock) represents the number of cycles since UNIX time. That is, it can assume that it was powered on at the moment of the UNIX epoch. That would be a valid implementation of system_clock. That time will likely not be correct in some absolute sense, but it will be a conforming C++20 implementation.
The standard simply requires system_clock's epoch to be UNIX time (or more specifically, we can all assume that it is UNIX time). That doesn't mean the tick count retrieved for the clock is guaranteed to be the globally accurate current time. After all, the user can technically change the current time, which is meant to be reflected in system_clock (which is why it is not required to be a steady clock).
As such, you could never assume that system_clock accurately represented the current time; it only represents what the operating environment thinks is the current time. So there is no way for chrono to explain that the current time is or is not "correct" in some sense.
system_clock is basically meant to provide whatever is the closest to the correct time-of-day that the system can provide or understand. If the best the system can do is to assume that the device was turned on at the UNIX epoch, then that's what you get.
Furthermore, since system_clock (and all of <chrono> for that matter) is not on the list of freestanding requirements, C++ implementations for such devices could be freestanding implementations. And therefore they choose not to implement system_clock (or all of <chrono>) at all.
answered 54 mins ago
Nicol Bolas
282k33466641
There is a distinction to be made between knowing the time, and knowing the correct time.
If such a device is turned on, it may freely assume that its CPU cycle counter (or whatever powers steady_clock) represents the number of cycles since UNIX time. That is, it can assume that it was powered on at the moment of the UNIX epoch. That would be a valid implementation of system_clock. That time will likely not be correct in some absolute sense, but it will be a conforming C++20 implementation.
The standard simply requires system_clock's epoch to be UNIX time (or more specifically, we can all assume that it is UNIX time). That doesn't mean the tick count retrieved for the clock is guaranteed to be the globally accurate current time. After all, the user can technically change the current time, which is meant to be reflected in system_clock (which is why it is not required to be a steady clock).
As such, you could never assume that system_clock accurately represented the current time; it only represents what the operating environment thinks is the current time. So there is no way for chrono to explain that the current time is or is not "correct" in some sense.
system_clock is basically meant to provide whatever is the closest to the correct time-of-day that the system can provide or understand. If the best the system can do is to assume that the device was turned on at the UNIX epoch, then that's what you get.
Furthermore, since system_clock (and all of <chrono> for that matter) is not on the list of freestanding requirements, C++ implementations for such devices could be freestanding implementations. And therefore they choose not to implement system_clock (or all of <chrono>) at all.
answered 54 mins ago
Nicol Bolas
282k33466641
edited 37 mins ago
answered 54 mins ago
Nicol Bolas
282k33466641
answered 54 mins ago
Nicol Bolas
282k33466641
answered 54 mins ago
Nicol Bolas
282k33466641
282k33466641
Interesting. So it could be the correct time, the incorrect time or even some fixed dummy time the device is set to when powered on that in no way correlates to any real time and it would still be conforming.
– Norask
28 mins ago
If a freestanding implementation implements everything fromchronoexceptsystem_clockit would still be conforming, right? There is no requirement in the standard that if a header is provided that it has to be provided fully, right?
– Norask
10 mins ago
1
@Norask:<chrono>is a header, not a library. There is only one standard library. And yes, for freestanding implementations, not all parts of a header have to be provided. That's why I said, "And therefore they choose not to implementsystem_clock(or all of<chrono>) at all.".
– Nicol Bolas
8 mins ago
add a comment |
Interesting. So it could be the correct time, the incorrect time or even some fixed dummy time the device is set to when powered on that in no way correlates to any real time and it would still be conforming.
– Norask
28 mins ago
If a freestanding implementation implements everything fromchronoexceptsystem_clockit would still be conforming, right? There is no requirement in the standard that if a header is provided that it has to be provided fully, right?
– Norask
10 mins ago
1
@Norask:<chrono>is a header, not a library. There is only one standard library. And yes, for freestanding implementations, not all parts of a header have to be provided. That's why I said, "And therefore they choose not to implementsystem_clock(or all of<chrono>) at all.".
– Nicol Bolas
8 mins ago
Interesting. So it could be the correct time, the incorrect time or even some fixed dummy time the device is set to when powered on that in no way correlates to any real time and it would still be conforming.
– Norask
28 mins ago
Interesting. So it could be the correct time, the incorrect time or even some fixed dummy time the device is set to when powered on that in no way correlates to any real time and it would still be conforming.
– Norask
28 mins ago
If a freestanding implementation implements everything from
chrono except system_clock it would still be conforming, right? There is no requirement in the standard that if a header is provided that it has to be provided fully, right?– Norask
10 mins ago
If a freestanding implementation implements everything from
chrono except system_clock it would still be conforming, right? There is no requirement in the standard that if a header is provided that it has to be provided fully, right?– Norask
10 mins ago
1
1
@Norask:
<chrono> is a header, not a library. There is only one standard library. And yes, for freestanding implementations, not all parts of a header have to be provided. That's why I said, "And therefore they choose not to implement system_clock (or all of <chrono>) at all.".– Nicol Bolas
8 mins ago
@Norask:
<chrono> is a header, not a library. There is only one standard library. And yes, for freestanding implementations, not all parts of a header have to be provided. That's why I said, "And therefore they choose not to implement system_clock (or all of <chrono>) at all.".– Nicol Bolas
8 mins ago
add a comment |
Norask is a new contributor. Be nice, and check out our Code of Conduct.
Norask is a new contributor. Be nice, and check out our Code of Conduct.
Norask is a new contributor. Be nice, and check out our Code of Conduct.
Norask is a new contributor. Be nice, and check out our Code of Conduct.
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f53997248%2fhow-can-a-conforming-c-implementation-indicate-that-it-doesnt-know-the-curren%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
1
Welp. Looks like a C++ implementation that cannot provide the current meatspace time would be non-conforming. That's not really a showstopper. It is not entirely unprecedented for special-purpose C++ implementation not to support this thing, or that thing. I wouldn't be surprised if a C++ implementation that's targeting some embedded platform doesn't have a
std::thread, for example.– Sam Varshavchik
1 hour ago
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
1 hour ago
Perhaps a compiler targeted at an architecture that does not support time should not implement
system_clockat all?– AndyG
52 mins ago
@StoryTeller Both. Freestanding implementations, however, could get around this by not providing the 'chrono' library at all (which would also exclude all other clocks).
– Norask
48 mins ago