[Issue 6725] core.time.dur should accept floating point

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Mon Jul 21 15:15:52 PDT 2014


https://issues.dlang.org/show_bug.cgi?id=6725

--- Comment #22 from Steven Schveighoffer <schveiguy at yahoo.com> ---
I think adding the 'best' way to convert a floating point to core.time may be
better than saying 'roll your own, and deal with floating point issues'.

Really, anyone can say: dur!"hnsecs"(val * (1000 * 1000 * 1000 / 100)), and
have a very bad conversion routine. This is not something we want people to do.

I'd rather have them do intervalToDuration(val), and do the best we can to
avoid rounding errors. Once you are in Duration land, calculations are sane.

(yes, I'm suggesting just a single function that only supports interval in
seconds instead of taking over functionality of dur)

(In reply to Jonathan M Davis from comment #16)

> Every application that I've seen use doubles for time has had bugs because
> of it.

I have a completely different experience, especially when the underlying core
library supports it.

> It works in a lot of cases, but you end up with subtle problems as a
> result.

I think this is an exaggeration. It works in nearly all cases, since the least
significant parts of a timestamp are not critical to get correct, and most
timing code does not use equality for comparison.

> Durations aren't as bad as timestamps, but it's still asking for
> trouble.

This begs the question, what trouble? While I have experienced and seen issues
with floating point, it has never been when checking if a timer has expired or
figuring out how long to sleep for. Can you state some examples?

--


More information about the Digitalmars-d-bugs mailing list