Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-03-28 18:42:43



Thanks for your positive review. I'm glad that the library is working
for you in a practical setting - that's always a concern for us
academics divorced from the real world ;^)

> specialization is simply the reciprocal of the first. Steven posted a
> solution to this in a separate thread just now and I hope that it will
> get included in the final version.

This should not be a problem; I'm accumulating a list of changes to
be made as they come in.

> Example 16 looks strangely familiar! Glad to see it was interesting
> enough to make the examples.

Your example was actually the impetus driving the decision to
implement heterogeneous units, a project that I know Steven spent a
significant amount of time and effort to get right...

> sure if this unit makes sense in the nautical namespace. One might
> ask "Why not boost::aerial?" The only reason I bring this up is
> because they are used for marine and aerial navigation. There may be

I tend to try to name things so they sound right if you read them;
even though they are used in aerial navigation, as far as I
understand they are still called nautical miles, so to my eye
nautical::miles reads right.

> other such examples, but I think all of the non_si_units.hpp units
> could reside in a boost::non_SI namespace with little confusion to the
> user. These would be all non-SI, but accepted, units (see

This is probably one of the darker corners left in the library; I'm
hoping that reviewer input will help to shape the final form of the
non-SI portion of the library. Steven has some ideas for dealing with
the irregularities of US/Imperial units in a relatively clean and
elegant way. However, putting all of these into the same namespace is
problematic because there are, for example, differing definitions of
units having the same name (mile, in particular) so us_customary,
us_survey, and nautical miles are all slightly discrepant.

> I also noticed that the unit knots was not defined in
> non_si_units.hpp. Is this an oversight? Why are some accepted non-SI
> units defined and others not?

I just have very limited personal experience with and use for these
traditional units, so I didn't think to add it. I'm certainly happy
to put knots in. I don't believe they were listed in the NIST
documents I was referencing. Because there are so many irregular
units out there, I'm reluctant to promise to support everything under
the sun in the library, but the decision of where to stop is a bit
arbitrary. I just used the NIST document as my yardstick (sorry...)

> Is there an exhaustive list in the docs mentioning all units and
> their systems?

There is not yet, but should be.

> Yes, certainly. I would, however, like to hear Matthias' and Steven's
> thoughts on how easy it would be to add a run-time layer on top of
> their existing work.

A runtime component would be essentially a parallel library that
replicated the existing dimensional analysis functionality in runtime
code. I've mentioned previously that it would be relatively easy to
specialize to get a syntax like quantity<arbitrary,Y> that looks much
the same as the existing syntax. It probably wouldn't be hard to
implement runtime algorithms; I am still extremely skeptical that
there are many users out there who would be willing to pay the
computational cost and memory overhead of doing all of the
dimensional analysis at runtime. At a bare minimum, I would like to
see some "real" use cases where it isn't possible to get reasonable
behavior with the existing library. As you mention, the current
implementation works fine with GUIs as long as you're willing to pick
an internal representation for the units used at compile time. There
would also need to be compile-time -> runtime conversions, input
parsing, etc... which would involve varying degrees of effort - the
latter probably will be hardest...


Boost list run by bdawes at, gregod at, cpdaniel at, john at