Re: [boost] Boost Units library preview

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-08-29 09:17:12

...dropping out of lurk mode for one comment...keeping in mind that I have not 
looked at the library or read a big chunk of this thread...

> About the unit I/O : I've though about providing a mechanism for it but decided
> later to drop it. The reason is that it adds nothing the user couldn't already
> do just as simply.
> 
> To provide output you need a symbol. This means that you need additional
> arguments to your units because you can not default generate one. As strings are
> very bad template arguments this will add at least one line of code. However in
> that case the user could also simply have written
> 
> ostream&operator<<(ostream&out, meter n){return out<<n.raw()<<"m";}
> 
> and he has the output exactly the way he wants. No problems with unicode or the
> symbol not being just the way the user wants it.
> 
> For the input you need a list of all inputable units, symbol position, raw
> number formats and symbols. In the best case this would be a long template
> argument list that reminds an if else chain. So why not simply use an if else
> chain like in the unit_converter.cpp example?

I/O turns out to be something that is quite difficult to do well.  There's 
plenty of issues like: support for wide streams, support for different domain 
contexts (eg: sometimes I want it to be 'm' and sometimes 'meters'), 
internationalization of number format, support for serialization. In 
date-time, there's probably more effort in I/O than any other single aspect of 
the library.

For me, a units library that doesn't seriously address I/O doesn't really 
finish the job of providing a set of types for application programmers that 
don't require major extension to use correctly.  The whole point of this 
should be that I can put a 'unit type' in place of an double or some native 
type.  If I have to write an ostream operator to use the library it doesn't 
make it as a 'double replacement'.

...back to lurk mode...

Jeff