I am no longer active in this community.

Oh, yes, I believe that was it. Just a code size optimization.

I agree that the change from size_t to uintptr_t is the right thing to do here. I don't recall exactly why I didn't use uintptr_t in the first place. It may have simply been an oversight. Or it may have been that uintptr_t wasn't in my toolbox at the time.

Thanks!

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.

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.

• msg-22467-327.txt265 BDownload
  • signature.asc848 BDownload

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.

Thanks Eric.

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.

I would like to offer two thoughts:

Look good to me.

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%).

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.

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.

Only tangentially related, here is some documentation on __next_prime: