datetime review part 2 [Update 5]

Dmitry Olshansky dmitry.olsh at gmail.com
Fri Nov 19 04:06:16 PST 2010


On 19.11.2010 15:00, Lars T. Kyllingstad wrote:
> On Fri, 19 Nov 2010 14:56:30 +0300, Dmitry Olshansky wrote:
>
>> On 19.11.2010 8:10, Jonathan M Davis wrote:
>>> Most Recent: http://is.gd/hovyR
>>>
>>> Other than some minor documentation changes, all of the changes are to
>>> the implementation rather than the API, though those changes are fairly
>>> minimal as well (albeit important).
>>>
>>> I fixed it so that the stopwatch code uses a monotonic clock on both
>>> Windows and Linux (at least, it will once clock_gettime() is fully in
>>> druntime rather than commented out) and so that getting the current
>>> time doesn't use a monotonic clock (before Linux was using a normal or
>>> real time clock for both whereas Windows was using a monotonic clock
>>> for both). I also consolidated some of the code in static ifs to
>>> minimize code duplication.
>>>
>>> As a reminder, if you want to use the code on Windows, you need to link
>>> with advapi32.lib.
>>>
>>> - Jonathan M Davis
>> Great!
>> Have you found a way to deal with high redundancy in API docs? For
>> instance in PosInfInterval (and in the others, most likely):
>>
>> template expand(D) if (__traits(compiles,begin + duration)) Expands the
>> interval backwards in time. Effectively, it does begin -= duration.
>> Parameters:
>> duration    The duration to expand the interval by. dir    The direction
>> in time to expand the interval. Examples:
>> [snip]
>>       nothrow void expand(D duration);
>>       Expands the interval backwards in time. Effectively, it does begin
>> -= duration.
>>       ...[exactly the same as above with examples ]..
>>
>> This appears to plague all the templated in such a way methods of all
>> Interval structs.
>>
>> Also, as  I said before,  summary table with common methods won't hurt.
>> In fact it would show the implicit interface - what TP provides, most
>> Intervals provide.
>>
>> As to my suggested API changes, now  I have a better plan for more
>> generic and easy to use API wrt ranges, just need some time to
>> experiment and write it down.
> I don't think there is much he can do about it, it's a bug in the
> compiler:
>
>    http://d.puremagic.com/issues/show_bug.cgi?id=4107
>
> -Lars
Ouch, thanks for the explanation.

-- 
Dmitry Olshansky



More information about the Digitalmars-d mailing list