1. 7

  2. 4

    Upvoted this article, because the topic is interesting, but not sure I concur with the conclusion and proposed solution of the author. I feel like there are good reasons to prefer ints over floats for time durations: easier to understand, less edge cases and maybe other reasons.

    When using std::chrono::minutes you basically sign up for time durations with a resolution of one minute. Not that suprising that adding seconds to that won’t work out nicely. Good API decision? - Debatable, but certainly not as horrible and unusable as made out by the author. The article seems quite arrogant to me.

    I personally would take ints over floats most of the time. (pun intended)

    1. 5

      I agree. My understanding of std::chrono‘s types is basically that they’re type-safe time units, C++-style. Of course you can’t add seconds to minutes, because they’re different types. Of course casting seconds to minutes backfires for this reason, just like char c += static_cast<char>(int{ 300 }) would. If you want typesafe units in C++, std::chrono is exactly the kind of API you come up with.

      I think I’d agree with the author that, more due to C++‘s unfortunate arithmetic behavior than anything else, std::chrono arguably has less intuitive interval results than, I dunno, Joda Time. But it’s worth noting that—again, if you think of std::chrono in terms of type-safe units—it’s not that bad, either. m += std ::chrono::duration_cast<std::chrono::minutes>(std::chrono::seconds{ 1 }); does fail because of rounding, but reversing the calculation to s += std ::chrono::duration_cast<std::chrono::seconds>(std::chrono::minutes{ 1 }); has the expected result. It might be nice if the first example didn’t compile, but, as I noted, this is basically normal C++ casting truncation.

      I dunno. I’m not going to say that std::chrono is the best API I’ve ever seen, but I’m entirely with you that the author’s rant seems misplaced.