>>> If the current code assumes a struct and the Windows API calls need an
>>> integer then either the existing code needs to be made more flexible,
>>> or you need to define it as a struct and then convert to an integer
>>> inside your new gthread wrapper functions.
>>
>> The Windows APIs involved use LARGE_INTEGER - a union of a 64-bit integer
>> and an array of two 32-bit integers - because some languages might have no
>> native 64-bit integer types.
>> Actually in C99 and C++11 we just assume there is long long and int64_t
>> despite the fact that ISO C marks int64_t as optional, so it can be regarded
>> as a union whose only element is an int64_t.
>>
> What are the units of the argument? Milliseconds?
>From Windows SDK:
File Times
A file time is a 64-bit value that represents the number of 100-nanosecond
intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated
Universal Time (UTC).
This decision makes it much easier to count leap years, no?
> You have two choices, either modify all the places in libstdc++ that
> use __gthread_time_t, changing the code to use some new function
> template that populates a __gthread_time_t from a
> std::chrono::time_point<C,D> or std::chrono::duration<R,P>, or define
> a similar struct in your gthreads header and convert it to int64_t
> inside your functions. For functions taking a relative time the
> conversion from a { seconds, nanoseconds } struct to milliseconds is
> trivial, for functions taking an absolute time you need to know the
> epoch of the clock that was used when populating the struct.
Will do that next week. Still need to make gcc work with my library.
------------------
Best regards,
lh_mouse
2016-04-18
