Boost logo

Boost :

From: Bill Seymour (bsey_at_[hidden])
Date: 2001-05-09 13:43:23


George Heintzelman wrote:
>
> Note that not all platforms support 64-bit ints directly.
>

Right. I'm actually thinking of two implementations: a maximally
portable one with an internal representation of 10's complement in
an array of char, one digit per char; and a less portable but more
efficient one with a boost::int_least64_t used internally. (If I
get excited, I might also do a BCD representation with lots of
inline assembler; but that wouldn't be an official Boost library
because it wouldn't be portable at all.)

>
> ... you must be able to do binary operations with all numeric
> types without having to do explicit type conversions; ...
>

Good point, although I'm concerned about needing a large number
of operator op= member functions. Also, allowing fixed-point
decimal and floating-point types in the same expressions could
give novices surprising answers, for example, when multiplying
by 3.5 and getting a double result. I'm not really sure what's
right; but I'm leaning towards requiring explicit conversions.

This actually came up in the J11/WG14 meeting in Copenhagen.
(We're working on a fixed-point binary type for embedded systems.)
One member wanted mixing fixed-point and floating-point types
to be a constraint violation; but there was virtually no support
for that in the full committee. Maybe I should take that as a
hint. 8-)

>
> Accountants often ... do what is known as the banker's round,
> rounding an exact 1/2 LSB to the nearest even digit ...
>

OK, I didn't know that. (I consider that good news, actually.)

>
> ... I'd also be interested in other ways of [constructing
> fixed-point decimal objects]. For example:
>
> typedef fixed<2> Money;
> Money wallet(12,53); // Puts $12.53 in my wallet.
>

Right, I've got that. (Forgot to mention it.)

>
> Make sure that fixed<0> also works transparently (and doesn't
> append a trailing radix character by default...).
>

Good point.

--Bill Seymour


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk