apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: more notes on the apr_time_t issue
Date Sat, 13 Jul 2002 18:02:49 GMT
On Sat, 2002-07-13 at 06:27, Jim Jagielski wrote:
> Justin Erenkrantz wrote:
> > 
> > 
> > Therefore, I think it has to be:
> > 
> > apr_dsec_t mytime = apr_time_dsec_now();
> > 
> > apr_busec_t mytime = apr_time_busec_now();
> > 
> How about apr_time_now(...) with an enum parameter that defines
> the return type.

I'd much rather have the entire API defined in terms of
binary microseconds (same function names that we have now,
but the argument type changes to apr_busec_t or whatever),
with conversion functions between apr_busec_t and

Given N functions and M data types, I'd much rather pick
*one* data type for use with all of those functions so
that we end up with O(M+N) functions instead of O(M*N).

There's already a precedent for this in libc: gettimeofday(),
for example, exists in one and only one form.  It populates
a struct timeval.  If your application prefers to work with
time_t or struct timespec or struct tm or anything else,
then the app is responsible for doing its own conversion.


View raw message