From: Andy Little (andy_at_[hidden])
Date: 2004-10-23 19:01:48
"Terje Slettebø" <tslettebo_at_[hidden]> wrote in message
> >From: "Andy Little" <andy_at_[hidden]>
> > I have been continuing with my physical-quantities library over the last
> > year,
> > http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html
> > and I am now seeking feedback as to whether it is worth putting this
> > as a boost library proposal....
> I'd be interested in such a library in Boost. It's also actually on the
> standards committee's "wishlist for C++0x"
> "a SI/Units library. ( e = m c2, and end to the mars lander crashes.)"
Yes I did see that. FWIW the highest priorities IMO would be threads,
networking and GUI , though in some cases I guess that this turns C++ from
a language to an Operating system ala Java. (And by threads I mean
major-language-upheaval-concept rather than low level widgets) Nevertheless
if C++ doesnt deal with these I think its going to get left behind
reasonably quickly. C++ certainly shouldnt be too proud to learn from Java.
I do see optimism in the GUI area and in threads if the concept approach
Anway the leap from my current reference impl to a boost version is probably
a big enough leap to contemplate ;-)
> I've been playing with a library like this, a year or so ago, too, but saw
> there were several proposals in that area, which worked similarily, and
> decided instead to focus on the Concept Traits library. I decided that I
> could then instead support other people's proposals in the area of
> quantity/units library.
> I've always seen this kind of library as a "fun" thing, :) as I'm
> in science, having "played with" electronics, physics, chemistry, etc.
> especially in my youth, and I'm sure such a library - of Boost standard
> (using modern C++), which this one seems to be - would be a great thing
> scientists, and people interested in science, everywhere.
The 'fun' thing is a key point of the library. Another useful feature is
consistency in converting between units, as well as the fact that each type
encodes a lot more information than a double, making it a C++ 'hub' for
conversion to-from eg XML , or the same entity in other programming
languages, data exchange , COM, CORBA etc. (Thats a theme I would like to
pursue in other areas such as graphics too) I hope to get to get to grips
with the serialisation library when the next boost distro comes out and try
to implement some of this. The other aspect is simply that of modelling. It
helps to visualise the entity you are modelling when the physical quantities
are named. That is difficult to describe rationally but certainly helps me
when I am coding. The fun aspect translates into much better understanding
of what source code is actually doing.
> I tried to test the library on Intel C++ 7.1 (electronics_example.cpp,
> picked at random) but got some errors which prevented the test, so I've
> tried it on g++ 3.2, instead, where it worked. Unless I haven't found it,
> you might want to include which compilers/versions it works for in the
> If you're interested in the diagnostics from Intel C++, I can mail them to
Yes I would be very interested in that naturally, maybe a boost post would
be most useful? It has only been tested on VC7.1 and gcc3.2.( As I
understand it the base level for a boost proposal is two compilers) Its in
the docs but will make it more prominent.. The docs need a lot of work in
> >From the examples and code I've looked at, it looks well designed and
> to use. You've obviously put a lot of work into this, both with the
> and documentation.
Yes and the more work I do on the project, the more I realise that I have
only just touched the surface. That is one downside if I prepare a boost
proposal.... I have the building blocks of the known universe in my hands.
The last thing I really want is to be documenting them, much rather wielding
them. (Ok.... IOW its a fascinating project to be working on whether it
becomes part of boost or no ;-) )
I also did some tests, myself, seeing how it dealt with
> the computation of units, and that worked fine.
> Sorry I can't give more feefback at this time - it's busy at work with
> days, these days. but I wanted to at least to chime in and say that, yes,
> I'd be interested in a such a library in Boost.
Thanks for the time you have spent and the comments. It is much appreciated.
> What might help is to give an overview of other libraries that exist for
> this, and what makes PQS different. One place to look is the Boost Files
> section (I saw at least three such libraries there).
This is a tricky area, as I have already spent considerable time criticising
other units libraries. What I will say is that I have looked at many if not
all the libraries on the file section and have learnt a lot from from all of
them. eg Eric Ford,Matthias Schabel, Phil Richards,Michael Kennistons
quantities library. (And BTW thanks too to Paul Bristow for the math
constants definitions) I hope that one major difference is in the level of
documentation and simply spending time on details, such as stream output.
The other major area that I have tried to address is the 'user-interface'
(Is there a less ghastly term for this ? ) . IOW I have tried to do this
from a users perspective.
I saw that Walter
> Brown's library is mentioned in the docs, though.
I think that SIUnits has a mythical status (The other well known work is in
the 'Barton-Nackman book, though I havent seen this) and has probably had
influence in a lot of areas eg mpl and metaprogramming. At the time it was
written it put huge demands on compilers, both requiring a reasonably
conforming compiler and in compile-times due to the large amount of
meta-programming involved. Things have improved making this type of library
much more practical these days. If SIUnits was put forward I would be happy
to step aside for it, but as I understand that is unlikely for various
> I think you should go ahead with it, and if it comes to formal review,
> make sure to do an in-depth study of it, preferably some time before the
Sounds like an offer I cant refuse. Thanks!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk