Re: [boost] Boost Units library preview

From: Ben Strasser (strasser.ben_at_[hidden])
Date: 2006-08-28 18:11:08

> However I disagree that users like to spend time making their own units. Quan
> has a fair number of units supplied(still nowhere near enough though) and when
> they are available they are very much more convenient to use. Also I/O is
> useful.
The original idea for this library was based on a real world example that you
certainly can't have in your library.

Consider a function grapher with a GUI and a scollable view of the graph. How
many different types of vectors (=points) do you have? There is "mathematical"
vector, meaning the solutions of the equations. Then there are those in virtual
screen coordinates, meaning a scroll undepand pixel fixed version. The relation
between "mathematical" vectors and virtual ones varies with the display setting
of the user so you can't hard code the realtions. And there are the scroll
relative vectors or also client area vectors. 

These are the 3 I though of when designing the app. Later I dicoverd 2 new ones
: The scroll position and window relative coordinates. You could also add screen
relative if you want to.

I doubt that you can provide a simple to use interface to differenciate these 6
units of vectors.

Another example would be games with an isometric grid. You will spend a lot of
time mapping vectors from grid coordinates to screen coordinates and back.

However you do have a point that it might be better to provide stock types. For
example the length quantity. It would make inoperation of code more easily. An
alternative would be to provide a sort of quantity cast that allows to bypass
the type check mechanism at junction points. 

The first option sounds better but the later is in my eyes more realisitc as you
will always forget at least one quantity.

> 
> I looked at how I would do the basic.cpp example 
> in Quan. Note that the units output comes
> in very handy here and also note the use of the 
> predefined units, which saves a
> lot of time and effort creating units.
> 

The basic example is also meant to be elementary so you can implement it
obviously better with elementary stock types. However how often do you calculate
the cinetique energie in real world examples?

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?