"Janek Kozicki" wrote
So with above citation to bring the context, the problem is that it's not easy to add new unit types. After short private correspondence with Andy I think there is a solution for that.
Instead of modifying the source code of the library, just add there following macro (macro name can be different of course):
#define BOOST_UNITS_DIVIDED(numerator,denominator,new_type) \ typedef /*typename */ pqs::meta::binary_operation< \ numerator, \ pqs::meta::divides, \ denominator \
::type new_type \
(this macro works in boost 1.33 - without boost::typeof. A similar macro can be written to utilize boost::typof. Of course a second macro BOOST_UNITS_MULTIPLIED would be needed as well)
This macro allows to define custom units with small trouble - just write the unit components. Taking example from my review - I had problems with a unit N/m (spring stiffness). With above macro I just write one line:
BOOST_UNITS_DIVIDED(pqs::force::N,pqs::length::m,N_div_m);
and now I have a new type named N_div_m and I can use it as desired.
Hopefully boost 1.34 will be released soon. Then Boost.Typeof will provide a generic solution to this problem rather than requiring a macro for each expression, Boost.Typeof can handle expressions of arbitrary complexity directly and IMO will be found to be extremely useful both inside and outside PQS library. IMO the fastest way to get full language support for decltype and auto(see below links): is to show how useful Boost.Typeof is and use it, use it, use it in preference to other type deduction schemes http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1478.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1527.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1705.pdf
With this mechanism maybe the amount of predefined units can be reduced - maybe even only to one unit per dimension and no mixed units at all?
I think there is a case for providing what I would call different 'views'. I have concentrated on one 'view' in which the units are explicitly spelt out. that is the one dealing with named-quantities, typedefs for particular units ( pqs::length::m) , etc, etc. This is helpful when unit conversions are needed. However, (though I havent looked in real detail at yade yet) http://yade.berlios.de/ from the current brief look I have had so far it occurs that for this type of use a different view, created by just typedefing quantities for their names (length, time, force etc) in implied base units, would be more suitable.( In yade I think the unit conversion capability is irrelevant ?). This type of use would also facilitate being able to switch PQS library in for dimensional analysis checking and then switch the library back to floating point types for max performance of the release version. In this case use of other than base units wouldnt be suitable, though even here unit conversions could be achieved ( maybe via the alternate syntax favoured by Walter Browns SI Units and Jesper Schmidt), if necessary. regards Andy Little