- User Since
- Oct 6 2013, 1:19 PM (363 w, 3 d)
Jun 9 2020
This is part of a larger design philosophy for the entire library. It is not necessarily a logic error to have a date or date component be in a state such that its .ok() returns false. There is an example demonstrating this idea here:
The spec does not allow year_month_day_last::day() to crash. It must not assert. It must not index an array out of bounds. It must not cause undefined behavior.
Nov 13 2019
I don't recall exactly what ELAST was for either. Though something like this is typically used to see if an enum/integral value is within the range of the declared enums.
Sep 18 2018
Oct 16 2017
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.
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 want to provide such a crutch.
Jan 4 2017
Dec 11 2016
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.
Dec 9 2016
I would like to offer two thoughts:
Jun 22 2016
Jun 15 2016
Look good to me.
Jun 14 2016
Can't call std::abs as it isn't constexpr. You'll have to roll your own.
I created a top-level gcd which did nothing but make everything unsigned and do the abs once, and then called a __gcd specialized for unsigned and only one kind of unsigned, and got measurably faster results (about 10%).
May 9 2016
Apr 29 2016
A quiet nan is the right tool. A signaling nan is nothing more than a 40-year-old design flaw. A quiet nan is "sticky" in that if you try to compute with it, the result is quiet nan. But you can assign a valid number to something containing a quiet nan. So if your answer has nans in it, you know you didn't initialize something properly somewhere.
Apr 27 2016
When in doubt, I find initializing to nan a safe thing to do. Either the code is correct, or the nan will find the bug.
Oct 2 2014
Only tangentially related, here is some documentation on __next_prime: