On Fri, 2 Jun 2000, Greg A. Woods wrote:

> [ On Friday, June 2, 2000 at 11:44:21 (+1000), Simon Burge wrote: ]
> > As to optimising the width calculations, currently it does for doubles
> > and ints something like:
> > 
> > 	if (mode == WIDTHMODE) {
> > 		asprintf(&buf, "%.*f", prec, val);
> 
> I was think it could do something even smarter that simply looked at the
> magnitude of the number knowing what base and format it would be
> converted into and didn't go about doing any actually conversions....
> 
> For example when converting to hex it's trivial to figure out how many
> digits you'll need.  For decimal numbers it's a bit harder, and I'm not
> sure if I'd want to tackle doing floating point in fewer CPU cycles than
> an actual conversion would take....
> 
> Of course for some non-numeric fields (eg. the start time, percentages,
> etc.) it's probably sufficient to hard-code the width.

	As a random thought, you could have the first pass print
	everything onto a linked list of strings in the '-q' format (or
	maybe separated with '\n' instead of ' '), making a note of the
	max lengths, and skipping the last entry (usually the command),
	then a second pass that takes each line and formats for output.

	From some samples here the memory overhead would average ~50
	characters per line (pointer + 45 chars).

		David/absolute
				       -- www.netbsd.org: No hype required --