Re: [boost] Boost Units library preview

From: Ben Strasser (strasser.ben_at_[hidden])
Date: 2006-08-29 12:23:30

Jeff Garland <jeff <at> crystalclearsoftware.com> writes:

> 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.
I fully agree with you.

> 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'.
I agree with you on this point. 

However I hope you do agree with me that everybody uses units a bit differently
so it is impossible to provide all possibilities. Even if you supported all
existing standards many people will want non standard units. This means that
most of the units will have to be user defined.

Now let us imagine we could realize every infterface we wanted. How would the
interface look like? For simple situations it should be simple and be able to
adabte to complex ones.

The simplest situation would be to have a non unicode unit postfix. So the ideal
interface would look similar to

typedef unit<length, "m"> meter;

by not providing I/O support we actually get extremly close to this

typedef unit<length> meter;
ostream&operator<<(ostream&out, meter n){return out<<n.raw()<<"m";}

It is indeed a bit verbose but every feasable unit interface is in my eyes more
verbose. The only real alternative is a macro that expands to the operator<<.

In more complex situations you run accross the problem that you can no longer
deduce the correct unit type. This is also the reason why PQU (= Physical
Quantities Units) has introduced annomymous units. However in what way does this
help? None that I can think of because in both situation (meaning non printable
units and annomymous units) the users has to indicate how to print the units.

The conclusion that I come to is there is nothing that even an ideal interface
could provide that isn't already just as simply possible with the interface the
iostreams provide for every type.

All you can do is making things more complicated.