[D-runtime] druntime commit, revision 410

[Sean Kelly]

On Nov 5, 2010, at 9:12 AM, Fawzi Mohamed wrote:

> On 5-nov-10, at 15:06, Sean Kelly wrote:
> 
>> On Nov 4, 2010, at 6:43 PM, Jonathan M Davis wrote:
>>> 
>>> Looking at core.time, I'd really suggest just moving over std.datetime.Duration
>>> to core.time along with TickDuration, FracSec, and the dur!() function for
>>> creating Durations, possibly along with some of the helper functions (which I
>>> believe are primarily restricted to template constraints).
>> 
>> Are there still 4 distinct duration types?
> 
> I really think that using doubles with the number of seconds for those "normal" usages is really better.
> That is what NSDate does (Next->Apple), and also libev.
> QT on the other hand uses a structure similar to the *nix timings, and Boost/std/tango
> The advantage of double is that it is a simple type, and introduces 0 dependencies, and is still flexible enough for most uses.

This would render the -nofloat compiler flag useless, but perhaps that isn't a huge issue.  It was one of the arguments for changing double->long for Thread.sleep() in Tango though.

> Using integers one has to somehow give access to the time unit in some way, and so make the interface more complex.
> If different timers have different resolution different structures have to be used.
> Thus they lead to a more complex interface.

I disagree.  With the Duration code, the call looks like this:

    Thread.sleep(seconds(5) + milliseconds(10))

How is that complex?  Though I'll admit that the double version is pretty straightforward too:

    Thread.sleep(5.01)

Or the conversion routines could be changed to return a double instead of a Duration:

    double seconds(T)(T val) {
        return cast(double) val;
    }

etc.  I'll admit that I'm not absolutely crazy about dealing with doubles inside the wait routines themselves, but this could be solved by the addition of some library functions.  I'd probably basically just rip out Duration and replace it with a bunch of free functions that did essentially the same thing: long hours(double), long nanoseconds(double), long totalNanoseconds(double), etc.

> Converting various native timers to a double might cost a little bit, but normally that is not a problem.

Since this will currently only be used for wait routines, the performance impact is irrelevant.