2 ms·
I was intrigued by this, and looked up: https://en.cppreference.com/w/cpp/chrono https://en.cppreference.com/w/cpp/chrono Yeah, it is a bit chaotic. ...but,
by Karellen 3y ago
I was intrigued by this, and looked up:
https://en.cppreference.com/w/cpp/chrono https://en.cppreference.com/w/cpp/chrono
Yeah, it is a bit chaotic.
...but, given that there often isn't just one "a time point from the OS", and thinking about the difference clock types on Linux (CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_BOOTTIME, etc...[0]), clocks and calendars are just messy. If you try and simplify them, you miss some edge cases which always end up being important to someone.
I guess there are just a bunch of tradeoffs that need to be made, and no matter which ones anyone makes, a lot of other people would have made different ones.
[0] https://manpages.debian.org/bookworm/manpages-dev/clock_getres.2.en.html https://manpages.debian.org/bookworm/manpages-dev/clock_getr...
- offices 3y agoFollowing my initial, post-compiler-upgrade disgust, I do think it's a wise tradeoff. I can't use clock_cast yet - so the workarounds are kludgy - but it's that kludge that itself tells you you're dealing with something complex.