howard.hinnant added a comment.
Ok. Well that's why it is under a #define: to make it easier to include or
not, depending on the needs of the platform.
https://reviews.llvm.org/D38599
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http:/
howard.hinnant added a comment.
Fwiw, I wrote this code. All of that "fallback" stuff was written to make
customer code that was incorrect, but working on OS X
-version-that-used-libsupc++ continue to work. I.e. to be a crutch for
incorrect code. It should all be removed if you no longer wan
howard.hinnant added inline comments.
Comment at: src/chrono.cpp:218
+#error "Never use CLOCK_MONOTONIC for steady_clock::now on Apple platforms"
+#endif
+
Nice, thanks!
https://reviews.llvm.org/D27429
___
cfe-comm
howard.hinnant added a comment.
Thanks Eric.
Fwiw `CLOCK_MONOTONIC` won't meet the requirements of the standard either. The
standard appears to require `steady_clock` to be a perfect clock and there is
no such thing. The wording used to only require monotonic, but the committee
got a little t
howard.hinnant added a comment.
One more comment: `steady_clock::now()` is not allowed to throw an exception
because it shall satisfy the requirements of `TrivialClock` ([time.clock]/p1).
And [time.clock.req]/p4/b4 says that a `TrivialClock::now()` does not throw
exceptions.
https://reviews
howard.hinnant added a comment.
I would like to offer two thoughts:
1. Timing with `steady_clock` is often used to time very short events. It
should be respected as the "high_resolution_clock". This means that two
consecutive calls to `steady_clock::now()` should return nanoseconds resolution
