Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk