http://llvm.org/bugs/show_bug.cgi?id=13721
Howard Hinnant <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Howard Hinnant <[email protected]> 2012-08-28 16:59:12 CDT --- <chrono> was intentionally designed to not be overflow-proof. However as long as you keep your durations down to +/- 292 years, you'll be ok, unless try to represent it with picoseconds. How about this: #include <chrono> #include <thread> int main() { typedef std::chrono::duration<int, std::ratio<24*3600>> days; typedef std::chrono::duration<int, std::ratio_multiply<days::period, std::ratio<3652425, 10000>>> years; std::this_thread::sleep_for(years(100)); } 100 years is an awfully long time to sleep. And when the computer mistakenly wakes 100 years from now, you'll have the satisfaction that your great grand children will have to take care of it. If that's not quite long enough, double it. If you would like to overflow-proof <chrono>, that can be done by creating an integral (or floating point) emulator that does whatever you like on overflow (throw? assert?), and then define duration units using that emulator. As long as your emulator detects the overflow when asked to convert to a std::chromo::nanoseconds::rep (long long), you're good to go. The 292 year thing comes from: typedef duration<signed integer type of at least 64 bits, nano> nanoseconds; 2^63 seconds is 292.277 years. It would hurt to clarify that information in a note. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
