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. _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
