Re: G_MICROSEC

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Wed, 6 Sep 2000, Sebastian Wilhelmi wrote:
> 
> > Hi Owen,
> > 
> > While trying to get rid of G_MICROSEC I'll noticed the following:
> > 
> > > After all, I think 1e6 is a valid integer constant in C. (gcc accepts it
> > > anyways.)
> > 
> > It isn't an integer constant, but a float one (I checked it in K&R). 

Doh .... I had forgot about the possibility of implicit conversion
for constants.

> > You mostly do not notice though, because gcc will optimize it, but
> > try "a = b % 1e6". That won't work.  Two options: 1) Let the user
> > use 1e6 hoping that the compiler will get things right. The user
> > will most certainly not need '%'.

I think this is to be avoided, since integer expressions 
will get promoted to double and then converted back. (And
writing (int)1e6 is just ugly.)  

> > 2) Define G_MICROSECS_PER_SEC or G_MICRO or maybe even G_MEGA to be 100000.
> 
> heck, couldn't we just put:
> 
> /* microseconds per second, convenience macro: */
> #define G_MICROSECS 1000000
> 
> picking something twice as long as 1000000 really makes
> matters inconvenient.

Well, the reason for having the macro are to :

 a) avoid typos
 b) avoid magic numbers

If the macro needs to be explained, then you loose the effect of b).
It's worth paying some extra length for that.

How about G_USEC_PER_SEC ? By GLib standards, that isn't a long
name, and since this is usually used in conjunction with the tv_sec
and tv_usec fields of GTimeVal, the abbreviation should be clear.

  if (data->expiration.tv_usec >= G_USEC_PER_SEC)
    {
      data->expiration.tv_usec -= G_USEC_PER_SEC;
      data->expiration.tv_sec++;
    }

Regards,
                                        Owen