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 Jan 1 at 16:56
user10605163
2,868624
asked Jan 1 at 16:52
NoraskNorask
14714
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 Jan 1 at 16:56
user10605163
2,868624
asked Jan 1 at 16:52
NoraskNorask
14714
3
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
Jan 1 at 16:56
1
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
Jan 1 at 16:58
Perhaps a compiler targeted at an architecture that does not support time should not implementsystem_clockat all?
– AndyG
Jan 1 at 17:11
@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
Jan 1 at 17:15
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 Jan 1 at 16:56
user10605163
2,868624
asked Jan 1 at 16:52
NoraskNorask
14714
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 Jan 1 at 16:56
user10605163
2,868624
asked Jan 1 at 16:52
NoraskNorask
14714
edited Jan 1 at 16:56
user10605163
2,868624
asked Jan 1 at 16:52
NoraskNorask
14714
edited Jan 1 at 16:56
user10605163
2,868624
edited Jan 1 at 16:56
user10605163
2,868624
edited Jan 1 at 16:56
user10605163
2,868624
2,868624
asked Jan 1 at 16:52
NoraskNorask
14714
asked Jan 1 at 16:52
NoraskNorask
14714
asked Jan 1 at 16:52
NoraskNorask
14714
14714
3
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
Jan 1 at 16:56
1
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
Jan 1 at 16:58
Perhaps a compiler targeted at an architecture that does not support time should not implementsystem_clockat all?
– AndyG
Jan 1 at 17:11
@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
Jan 1 at 17:15
add a comment |
3
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
Jan 1 at 16:56
1
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
Jan 1 at 16:58
Perhaps a compiler targeted at an architecture that does not support time should not implementsystem_clockat all?
– AndyG
Jan 1 at 17:11
@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
Jan 1 at 17:15
3
3
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
Jan 1 at 16:56
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
Jan 1 at 16:56
1
1
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
Jan 1 at 16:58
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
Jan 1 at 16:58
Perhaps a compiler targeted at an architecture that does not support time should not implement
system_clock at all?– AndyG
Jan 1 at 17:11
Perhaps a compiler targeted at an architecture that does not support time should not implement
system_clock at all?– AndyG
Jan 1 at 17:11
@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
Jan 1 at 17:15
@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
Jan 1 at 17:15
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 Jan 1 at 17:09
Nicol BolasNicol Bolas
289k33480651
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
Jan 1 at 17:36
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
Jan 1 at 17:53
4
@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
Jan 1 at 17:55
1
The accuracy of timing functions is a Quality of Implementation issue. There are many ways in which a conforming implementation could be of such poor quality as to be useless. A good quality implementation should report the time reasonably accurately when practical, but the fact that the returned time is off by an hour or even a decade would not make an implementation non-conforming.
– supercat
Jan 1 at 20:40
1. "That is, it can assume that it was powered on at the moment of the UNIX epoch" - That's not the same as the previous sentence, and AFAICT you can't assume the CPU was powered on at the UNIX epoch. 2. If you refer both tosteady_clockandsystem_clockyou should say something about their difference; perhaps you could consider only referencing one of them to make things simpler.
– einpoklum
Jan 1 at 21:31
|
show 2 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%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 Jan 1 at 17:09
Nicol BolasNicol Bolas
289k33480651
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
Jan 1 at 17:36
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
Jan 1 at 17:53
4
@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
Jan 1 at 17:55
1
The accuracy of timing functions is a Quality of Implementation issue. There are many ways in which a conforming implementation could be of such poor quality as to be useless. A good quality implementation should report the time reasonably accurately when practical, but the fact that the returned time is off by an hour or even a decade would not make an implementation non-conforming.
– supercat
Jan 1 at 20:40
1. "That is, it can assume that it was powered on at the moment of the UNIX epoch" - That's not the same as the previous sentence, and AFAICT you can't assume the CPU was powered on at the UNIX epoch. 2. If you refer both tosteady_clockandsystem_clockyou should say something about their difference; perhaps you could consider only referencing one of them to make things simpler.
– einpoklum
Jan 1 at 21:31
|
show 2 more comments
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 Jan 1 at 17:09
Nicol BolasNicol Bolas
289k33480651
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
Jan 1 at 17:36
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
Jan 1 at 17:53
4
@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
Jan 1 at 17:55
1
The accuracy of timing functions is a Quality of Implementation issue. There are many ways in which a conforming implementation could be of such poor quality as to be useless. A good quality implementation should report the time reasonably accurately when practical, but the fact that the returned time is off by an hour or even a decade would not make an implementation non-conforming.
– supercat
Jan 1 at 20:40
1. "That is, it can assume that it was powered on at the moment of the UNIX epoch" - That's not the same as the previous sentence, and AFAICT you can't assume the CPU was powered on at the UNIX epoch. 2. If you refer both tosteady_clockandsystem_clockyou should say something about their difference; perhaps you could consider only referencing one of them to make things simpler.
– einpoklum
Jan 1 at 21:31
|
show 2 more comments
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 Jan 1 at 17:09
Nicol BolasNicol Bolas
289k33480651
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 Jan 1 at 17:09
Nicol BolasNicol Bolas
289k33480651
edited Jan 1 at 17:26
answered Jan 1 at 17:09
Nicol BolasNicol Bolas
289k33480651
answered Jan 1 at 17:09
Nicol BolasNicol Bolas
289k33480651
answered Jan 1 at 17:09
Nicol BolasNicol Bolas
289k33480651
289k33480651
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
Jan 1 at 17:36
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
Jan 1 at 17:53
4
@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
Jan 1 at 17:55
1
The accuracy of timing functions is a Quality of Implementation issue. There are many ways in which a conforming implementation could be of such poor quality as to be useless. A good quality implementation should report the time reasonably accurately when practical, but the fact that the returned time is off by an hour or even a decade would not make an implementation non-conforming.
– supercat
Jan 1 at 20:40
1. "That is, it can assume that it was powered on at the moment of the UNIX epoch" - That's not the same as the previous sentence, and AFAICT you can't assume the CPU was powered on at the UNIX epoch. 2. If you refer both tosteady_clockandsystem_clockyou should say something about their difference; perhaps you could consider only referencing one of them to make things simpler.
– einpoklum
Jan 1 at 21:31
|
show 2 more comments
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
Jan 1 at 17:36
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
Jan 1 at 17:53
4
@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
Jan 1 at 17:55
1
The accuracy of timing functions is a Quality of Implementation issue. There are many ways in which a conforming implementation could be of such poor quality as to be useless. A good quality implementation should report the time reasonably accurately when practical, but the fact that the returned time is off by an hour or even a decade would not make an implementation non-conforming.
– supercat
Jan 1 at 20:40
1. "That is, it can assume that it was powered on at the moment of the UNIX epoch" - That's not the same as the previous sentence, and AFAICT you can't assume the CPU was powered on at the UNIX epoch. 2. If you refer both tosteady_clockandsystem_clockyou should say something about their difference; perhaps you could consider only referencing one of them to make things simpler.
– einpoklum
Jan 1 at 21:31
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
Jan 1 at 17:36
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
Jan 1 at 17:36
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
Jan 1 at 17:53
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
Jan 1 at 17:53
4
4
@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
Jan 1 at 17:55
@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
Jan 1 at 17:55
1
1
The accuracy of timing functions is a Quality of Implementation issue. There are many ways in which a conforming implementation could be of such poor quality as to be useless. A good quality implementation should report the time reasonably accurately when practical, but the fact that the returned time is off by an hour or even a decade would not make an implementation non-conforming.
– supercat
Jan 1 at 20:40
The accuracy of timing functions is a Quality of Implementation issue. There are many ways in which a conforming implementation could be of such poor quality as to be useless. A good quality implementation should report the time reasonably accurately when practical, but the fact that the returned time is off by an hour or even a decade would not make an implementation non-conforming.
– supercat
Jan 1 at 20:40
1. "That is, it can assume that it was powered on at the moment of the UNIX epoch" - That's not the same as the previous sentence, and AFAICT you can't assume the CPU was powered on at the UNIX epoch. 2. If you refer both to
steady_clock and system_clock you should say something about their difference; perhaps you could consider only referencing one of them to make things simpler.– einpoklum
Jan 1 at 21:31
1. "That is, it can assume that it was powered on at the moment of the UNIX epoch" - That's not the same as the previous sentence, and AFAICT you can't assume the CPU was powered on at the UNIX epoch. 2. If you refer both to
steady_clock and system_clock you should say something about their difference; perhaps you could consider only referencing one of them to make things simpler.– einpoklum
Jan 1 at 21:31
|
show 2 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%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
3
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
Jan 1 at 16:56
1
Are you asking about freestanding implementations specifically, or hosted ones with possibly no time facilities?
– StoryTeller
Jan 1 at 16:58
Perhaps a compiler targeted at an architecture that does not support time should not implement
system_clockat all?– AndyG
Jan 1 at 17:11
@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
Jan 1 at 17:15