"Paul Mensonides" wrote
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little
This (my small sample code) is in no way supposed to be a full-blown library, BTW. It is just for amusement.
How about rational dimension elements rather than integers. Would that be possible using the preprocessor?
The preprocessor isn't doing the work. It is just generating the code that does the work. Use of the preprocessor (here) is just making all that code write itself based on an initial sequence of fundamental units.
Unfortunately it wont compile on VC7.1, though I preprocessed it . Seems to be based on doing maths inside array brackets to get different sizes? Sounds quite like Boost.Typeof though more direct maths!
This occurs rarely but needs to be possible. One example is in measuring electrical noise where units for noise-voltage density are Volts * (Hertz to_power -1/2). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Out of curiosity, how does this occur starting from SI's fundamental units?
if : K is boltzmanns constant which is approx 1.38 e-23 Joules per Kelvin T is absolute temperature in Kelvin R is resistance in Ohms then Johnson noise density in Volts / (Hertz to_power 1/2). == sqrt( 4 * K * R * T); However volts, energy and resistance are all compound units of course . resistance = voltage / current, power = current * voltage, power = energy / time, energy = force * distance, force = mass * acceleration, acceleration = distance / (time*time). I think its possible to derive the units of johnson noise density from fundamental units that way.
The time element of the dimension works out as being to power -(2 1/2) FWIW!
You can certainly implement a static rational with a little template metaprogramming. Reducing rational values with template metaprogramming would be expensive in general, but here were mostly talking about very "small" rationals. You'd just end up with two "fields" per dimension (numerator and denominator) instead of one, and you'd have to use them as rational values. E.g. the way that I wrote it, you basically have:
dim<mass, time, ...>
...where 'mass' and 'time' are integers. Instead, you have to have 'mass' and 'time' be types that represent rational values (such as 'rational<-5, 2>').
Right (and I understand its for fun) , but presumably there is unlikely to be an advantage over using templates in compilation speed and certainly not in legibility ? FWIW I have finally started using the preprocessor library in pqs. I needed to generate a large number of power of 10 functors with a rational exponent and where the range is configurable by the user via a config macro. (For anyone interested these functors are in <boost/pqs/detail/united_value/operations/coherent_exponent_eval.hpp>. note: pqs is in the review queue but not an official boost library ) The preprocessor code I ended up with is basically copied from http://boost-consulting.com/tmpbook/preprocessor.html ,which I found thanks to the useful link in the preprocessor docs ;-). seems to work well but I dont make any claim to really understand how it works though! (note: I'm quite happy to leave it that way too unless I really need to know otherwise ;-))
The things that I find amusing in it are that dimensions are specified using variables, not types (somewhat unusual), and the way that the reconstruction of type from variables occurs.
Is that the same as how Boost.typeof works ...?
[..]
It is probably similar (as far as reconstruction goes). I think that specifying dimensions using variables instead of types is different. Instead of the above, you have something like:
[cut example]
All of the above are variable declarations, not typedefs. They are variables that have no function except to be used in expressions for the purpose of extracting type. In a scheme like this, the user never even sees the actual types of these variables. Instead, the type is 'named' via an expression.
Presumably there is a chance that these end up in the executable though which could tend to get messy? [...]
All of this is slightly more complex that what I wrote (which is no where near being a full-fledged physical quantities library), but it is all possible.
I have to admit that I prefer to use the preprocessor as a last resort, however that might be seen as an improvement on my previous position which was to avoid its use at all if possible. Nevertheless I have found the Boost.Preprocessor library really useful recently as said above and also just plain impressive because it seems to makes use of the preprocessor a bit more like a traditional programming language, hence easier to understand or even just plain useable. The Preprocessor library has to be the most original boost library I reckon! regards Andy Little