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

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Tue Jul 22 23:48:56 PDT 2014


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

--- Comment #25 from Sobirari Muhomori <dfj1esp02 at sneakemail.com> ---
(In reply to Vladimir Panteleev from comment #7)
> This argument is exaggerated. Not all measurements of time need to be
> precise. For example, if an utility program could accept a timeout value
> from the user, it's more useful to allow them to specify a fractional value.

That's an overengineered interface and should be done in your code. Fractions
of timeouts are practically indiscernible, nobody would need to specify it that
way.

(In reply to Steven Schveighoffer from comment #22)
> > 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.

We were unfortunate enough to depend on exact match of timestamps: an
electronic signature algorithm dictates that signatures must be certified with
a timestamp, so as the timestamp is hashed, it must match to the last bit and
in our case it should work reproducibly across the following set of
technologies: x86-32, x86-64, arm32, arm64, soft float, hard float, windows,
linux, iOS, android, .net, java, obj-c, delphi, c++.

The examples presented are quite esoteric and don't prove necessity of having
floatDur in standard library. Though, floatDur can be included in docs to help
people copy it if they really need it.

--


More information about the Digitalmars-d-bugs mailing list