|
Boost : |
From: Andy Little (andy_at_[hidden])
Date: 2004-01-27 03:40:13
"Fernando Cacciola" <fernando_cacciola_at_[hidden]> wrote
>
> "Andy Little" <andy_at_[hidden]> escribió
> The idea is that the user of value_type_traits plugs in her own converter,
> which can be easily composed out of boost::numeric::converter by
derivation.
> Looks nice to me.
Yes and furthermore I could implement as a default, conversions for S.I.
physical-quantities as laid out in The "Guide for the Use of the
International System of Units (SI) NIST 811. Appendix B (Conversion
factors) , B.7.1 Rounding Numbers ... (Uses a form of 'nearest neighbour'
rounding [on xx.5...LSbit_ofxx ==1 -->high, LSbitofxx ==0 --> low etc] I
think.) :-) 'Assembler' guys may decide they dont need the loss in speed...
so a (the) raw converter comes in useful.
OTOH the tricky part is that if I use numeric::converter I am going to have
to take some responsibility for exceptions thrown. As many potential users
may be inexperienced they may start blaming my library when it does the
right thing. :-) .
With safe conversions in mind, ultimately it might be nice to have a 'safe
maths' environment:
Assume an int16 is 16 bits, int32 is 32bits etc
Taking int16 as example, the declaration of operator*(int16,int16) would
look like so:
int32 operator * (int16, int16);
Note the return value is an int32. Therefore there is a Guarantee that there
is no chance of overflow in the calculation itself. The result can be
checked as an int32 for int16 range before being converted back to an
int16.( As I work with 8 bit micros the full family would include; int24
operator*(int8,int16) etc )
With that sort of framework implemented in a version of the class itself,
you could start to make pretty strong guarantees about correct results,
which is more important than raw speed in many applications.
Thanks again Fernando( and everyone who has worked on the
boost::numeric::converter). It opens up a lot of interesting possibilities.
:-)
regards
Andy Little
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk