(2010/09/27 20:22), Jonathan M Davis wrote:
Well, it should be less then a week before I'm done (hopefully sooner rather
than later), but I keep ending up having to refactor things, and I haven't
always had as much free time as I expected, so it's been taking me longer than I
expected. I'll post it here as soon as it's ready, and then everyone can review
it.
I don't know about your Duration, but normally a duration would be a value and
units, while my ticks are just units. For instance, I declare this enum
Correct! You shouldn't see my 'std.time'. There is the doubt why poison
is mixed with in the code.
/++
Represents possible units of time.
+/
enum TUnit { year, month, week, day, hour, minute, second, millisecond,
microsecond, stdTick }
to represent all the possible units of time (it was tick until I changed it to
stdTick). Your Ticks, on the other hand, is a value with variable units, so it's
kind of like a duration, except that it's specifically a duration since midnight
January 1st, 1970. So, like time_t, it could be viewed as a duration (or as an
interval for that matter since it has a fixed point for its start), but it's
used
more like a point in time. In fact, now that I think about it, in boost
terminology, it really is a time point; it just lacks all of the trappings that
let it work with durations, and intervals, and iterators/ranges, and the like.
In any case, what my code means by tick (or stdTick) is totally different from
what Ticks does.
Ticks is not a time point. It is rather near to a time span. It is a
time span since indeterminate time point that may not be midnight
January 1st, 1970 and may be when you started a StopWatch.
I'm tempted to rename Ticks to PrecisionTime or something similar, since that's
more or less what it is. It's a time point with the maximum precision that the
system clock has to offer. Unfortunately, even doing that doesn't quite fix the
ticks problem, since it would still have ticksPerSecond. I'd be tempted to
change it to the number of ticks in its precision (e.g. a clock with microsecond
precision - 1 million ticks per second - would be 10 std ticks, whereas a clock
with millisecond precision would be 1000 std ticks) - it would make it so that
there was only one type of tick. Unfortunately, that falls apart once your
precision goes beyond 10 million ticks per second (1 std tick), since then you'd
get fractional std ticks, and any computer with nanosecond precision would
obviously fall in that category. ticksPerSecond, at least, scales to no matter
what resolution the system clock has.
Therefore I am against PrecisionTime.
What I'd really like is to find a better name than tick or std tick for my
ticks.
What would that be anyway? A deci-microsecond? A centa-nanosecond? Either name
would be horrible.
As for merging your code, it's mostly been just copy and paste. The only things
that I've changed thus far are adding the ability to get std ticks out of Ticks
and fixing it so that Ticks works with precision less than a microsecond. For
instance, toMicroseconds() is now
const
T toMicroseconds(T)() if (isIntegral!T&& T.sizeof>= 4)
{
if(ticksPerSec>= 1_000_000)
return value / (ticksPerSec / 1_000_000);
else
return value * (1_000_000 / ticksPerSec);
}
The problem was that dividing by 1_000_000 when the precision is less than that
resulting in a floating point exception (I ran into it because I added std ticks
and my system clock has microsecond precision). Other than that, your code is
exactly as it is in std.datetime right now. Oh, and I had to add an alias for
TemporaryValue, otherwise compilation failed when attempting to produce ddoc
files.
The one thing that I think that I'm going to change at this point is the name of
the Ticks struct. The best that I can think of at the moment is PrecisionTime,
but I'm open to suggestions (that is why I started this thread, after all).
In any case, hopefully it won't be much longer before I'm able to post the
finished result here for review.
- Jonathan M Davis
Because your Ticks is completely different from mine, there must not be
misunderstanding for each name.
SysSpan/SysDuration/SysPeriod/PerfSpan/PerfDuration/PerfPeriod/SysClockSpan/SysTicks/PerfTicks/PrecisionSpan/PrecisionDuration/PrecisionPeriod/...etc.
Please pick your favorite name.
I don't know English little nuances well... If the name does not provoke
misunderstanding, I am not particular about the name.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
