apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: more notes on the apr_time_t issue
Date Sat, 13 Jul 2002 06:12:25 GMT
On Fri, Jul 12, 2002 at 10:50:36PM -0700, Brian Pane wrote:
> Agreed.  And that API includes:
>     type_name_tbd operator+(type_name_tbd a, type_name_tbd b);
>     type_name_tbd operator-(type_name_tbd a, type_name_tbd b);

Right.

> > If that bugs you (and it well might), then we need to go the
> > apr_busec_t route and rename every APR time function.  -- justin
> 
> -1 for renaming any APR time functions: just rename the data type.

If you go to a contract for the time, I think you need to have
specific APR functions that go with that.  My earlier example was
that I might want apr_dsec_t as well.  Therefore, to eliminate
confusion, we have to have that type's functions strongly related
to the type as there would be no generic time structure.  It
would be possible to have type confusion.  Because, a user might
inadvertently do the following.

apr_dsec_t mytime = apr_time_now();

But, wait, you want apr_time_now() to return an apr_busec_t.  Will
the compiler issue a warning or an error here?  In the common case,
they will both be scalar, so I think the compiler just might issue
an warning (or perhaps nothing at all).

Therefore, I think it has to be:

apr_dsec_t mytime = apr_time_dsec_now();

apr_busec_t mytime = apr_time_busec_now();

(time_ does not have to be in the function name.)

My $.02.  -- justin

P.S.  Try http://www.apache.org/~jerenkrantz/types.c with your
compiler!

Mime
View raw message