From: Matthias Schabel (boost_at_[hidden])
Date: 2004-01-08 11:10:52
> I think a good starting point for reducing compile time, and more
> importantly, *code-writing time* would be to shorten those names.
I don't really know about compile time reduction - a smart compiler
will undoubtedly use a hash of some sort to reduce names into integers
or something more manageable... As far as code-writing time goes, I
guess I spend so much more time thinking about implementation and
algorithms than actually typing code that the long names are not an
issue. I also have a personal preference for completely unambiguous
naming and, in this case, most users won't see this verbose stuff as it
is more internal to the library. On the other hand, I'm not
particularly strongly attached to this particular choice of names...
> template<class Y>
> dimensioned_quantity<Y,dimensioned_unit<si_model,quantity_type> >
> (dimensioned_quantity<Y,dimensioned_unit<si_model,pressure_ty pe> > P,
> dimensioned_quantity<Y,dimensioned_unit<si_model,volume_type> > V,
> dimensioned_quantity<Y,dimensioned_unit<si_model,temperature_type> > T)
> return (P*V/(8.314*(_joules/(_kelvin*_mole))*T));
This snippet is carrying some baggage from an earlier version which was
not specifically tied to the SI model; i.e. it was written to deal with
arbitrary unit systems. A more concise version with the existing
library would be :
idealGasLaw(typename SI<Y>::pressure P,
typename SI<Y>::volume V,
typename SI<Y>::temperature T)
> Another question in my mind is what's the reason to have
> "pressure_type", or "temperature_type"? Are they actually doing any
These are the actual lists of abstract dimensions - pressure_type is
this typedef :
// l^-1 m t^-2
dim<time_tag,static_rational<-2> > >
> Another question I have is about the purpose for "si_model" above.
> Here in Canada we constantly mix metric and imperial units. If one
> was working on software that controls a rover on a distant planet, I
> can see a good reason to restrict the units to a closed system; and I
> wouldn't mind having the ability to set a compile time constant that
> effects such restriction. But if I'm working on a circuit layout CAD
> application, most lead-through components are dimensioned in mils
> (inches/1000), while most surface-mount components are dimensioned in
> But most of all, I'd hate to have to type "si_model", "si_model",
> "si_model", "si_model", "si_model",... many times a day.
The question of mixing units from different systems treads on the
sticky ground of unit conversions and whether (and if so, when) they
should be implicit or strictly explicit. From a safety perspective, it
seems that requiring explicit conversions is the most conservative, but
opinions definitely differ widely on the point. If you're willing to
deal with unit conversions on initialization, you can just do things
and have all the internal stuff done in SI. I have thought about the
possibility of doing away with unit models entirely - the only problem
is then you need to define some absolute reference for conversions
which can cause problems if you want a system which deals with the
Planck length as a natural quantity (10^-33 m) and want to convert to
attometers or something else small - if the common base is SI, you
potentially end up with precision problems.
> template< typename Y >
> Y idealGasLaw( pascals<Y> p, litres<Y> v, kelvins<Y> t );
> Kelvins should _themselves_ 'know' that they are a temperature type.
> And if I threw Celsius at it, it should know what to do, too.
This is a perfect opportunity for template typedefs; it would be great
to just be able to do something like
template<class Y> typedef
That would make me a happy person... As far as Celsius goes, I am
still ruminating on a way to deal with more complex unit conversions
(affine rather than linear in this case, but potentially nonlinear for
other unit types) without incurring unnecessary overhead where you
don't need it.
Matthias Schabel, Ph.D.
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT 84108
mschabel at ucair med utah edu
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk