On Sep 27, 2010, at 10:08 PM, Robert Jacques wrote:
> 
> Well, if you make up a unit, then you can guarantee no one will have heard of it before. And really, learning the hecto SI prefix means someone will always understand what hectonanosecond means, as opposed to StdTick or Duration, etc, which would have a tendency to be quickly forgotten or confused with another library type from another language. As for typing, I would expect the 100ns unit to be mainly an internal thing. Most of the time I deal in microseconds/1000.0 (i.e. floating point milliseconds), when dealing with std.perf today.


The Boost TimeDuration struct has a ticks() method as well as a few methods describing the tick resolution.  So someone wanting to possibly avoid a conversion could do:

if (7 == x.num_fractional_digits())
    auto y = x.ticks();
else
    auto z = x.total_nanoseconds() / 100;

This is what I'm currently working with for durations in druntime (not yet committed).

On Tuesday, September 28, 2010 07:40:50 Sean Kelly wrote:
> On Sep 27, 2010, at 10:08 PM, Robert Jacques wrote:
> > Well, if you make up a unit, then you can guarantee no one will have heard of it before. And really, learning the hecto SI prefix means someone will always understand what hectonanosecond means, as opposed to StdTick or Duration, etc, which would have a tendency to be quickly forgotten or confused with another library type from another language. As for typing, I would expect the 100ns unit to be mainly an internal thing. Most of the time I deal in microseconds/1000.0 (i.e. floating point milliseconds), when dealing with std.perf today.
> 
> The Boost TimeDuration struct has a ticks() method as well as a few methods describing the tick resolution.  So someone wanting to possibly avoid a conversion could do:
> 
> if (7 == x.num_fractional_digits())
>     auto y = x.ticks();
> else
>     auto z = x.total_nanoseconds() / 100;
> 
> This is what I'm currently working with for durations in druntime (not yet
> committed).

I do believe, however, that Boost's definition of ticks varies with the resolution of the system clock - so it's really more along the lines of ticks per second like SHOO's Ticks struct uses than a fixed unit of time. That can be useful for some stuff, but it's not the sort of thing that I'd expect many programs to want to use directly. The datetime code needs to know how many ticks per seconds it's dealing with so that it can correctly convert high-precision time to known units - such as microseconds, nanoseconds, etc. - but doing stuff like creating a duration of a specific number of ticks doesn't strike me as being particularly useful - much as Boost does supply the means to do it. I certainly wouldn't want to have to worry about having a bunch of ifs or static ifs in my normal code to deal with varying tick resolution. Ideally, the date/time library code would abstract that out so that I don't have to worry about it. None of my datetime code uses variable unit sizes. The closest it does is to translate SHOO's Ticks struct to hecto-nanseconds when it gets the current time. After that, all of the units are of known and fixed size.

- Jonathan M Davis

On Sep 28, 2010, at 10:57 AM, Jonathan M Davis wrote:

> On Tuesday, September 28, 2010 07:40:50 Sean Kelly wrote:
>> On Sep 27, 2010, at 10:08 PM, Robert Jacques wrote:
>>> Well, if you make up a unit, then you can guarantee no one will have heard of it before. And really, learning the hecto SI prefix means someone will always understand what hectonanosecond means, as opposed to StdTick or Duration, etc, which would have a tendency to be quickly forgotten or confused with another library type from another language. As for typing, I would expect the 100ns unit to be mainly an internal thing. Most of the time I deal in microseconds/1000.0 (i.e. floating point milliseconds), when dealing with std.perf today.
>> 
>> The Boost TimeDuration struct has a ticks() method as well as a few methods describing the tick resolution.  So someone wanting to possibly avoid a conversion could do:
>> 
>> if (7 == x.num_fractional_digits())
>>    auto y = x.ticks();
>> else
>>    auto z = x.total_nanoseconds() / 100;
>> 
>> This is what I'm currently working with for durations in druntime (not yet
>> committed).
> 
> I do believe, however, that Boost's definition of ticks varies with the resolution of the system clock - so it's really more along the lines of ticks per second like SHOO's Ticks struct uses than a fixed unit of time.

It's a template, and the resolution can be chosen at compile-time.  I think this is actually a bit too flexible, but I still like the idea that there should be no published tick resolution, so if it changed from nanoseconds to 100 nanoseconds or whatever then user code should continue to work without changes.

> That can be useful for some stuff, but it's not the sort of thing that I'd expect many programs to want to use directly. The datetime code needs to know how many ticks per seconds it's dealing with so that it can correctly convert high-precision time to known units - such as microseconds, nanoseconds, etc. - but doing stuff like creating a duration of a specific number of ticks doesn't strike me as being particularly useful - much as Boost does supply the means to do it. I certainly wouldn't want to have to worry about having a bunch of ifs or static ifs in my normal code to deal with varying tick resolution. Ideally, the date/time library code would abstract that out so that I don't have to worry about it.

Agreed.  There are methods for converting to seconds, milli, micro, and nanoseconds so those should work for most cases.  I think it would be rare that someone would use ticks() directly.

On Tue, 28 Sep 2010 13:05:55 -0500, Sean Kelly <sean at invisibleduck.org> wrote:

> Agreed.  There are methods for converting to seconds, milli, micro, and nanoseconds so those should work for most cases.  I think it would be rare that someone would use ticks() directly.

-- 
I think that the thicks() method is mostly used for conversions.

On Tue, Sep 28, 2010 at 09:39, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>
> Well, it's not entirely made up. 100ns is the tick that Windows uses.

A few suggestions, some quite tongue in cheek:

WindowsTicks
RedmondTicks
Seconds!(-7)  (Seconds!(-6) are microseconds, etc.)
Tocks

The HNSeconds suggestion by Andrei has the interesting side effect than, when people will ask what H mean, you can answer hundred instead of hecto :)