Re: [boost] Re: Fixed point decimal

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-05 14:00:08

At 03:32 PM 9/4/2002, Bill Seymour wrote:

 >Beman Dawes wrote:
 >>
 >> I wrote some accounting software once for a petroleum distributor.
 >> Price (dollars per gallon, 4 places) times quantity (in gallons,
 >> 1 place) yielded invoice amount (in dollars, 2 places).
 >>
 >
 >And Jeff Garland responded:
 >>
 >> Sure, but you could do all of this using 4 places and then round
 >> off to two with the final result.  This would at most require a
 >> couple of conversion operations which I was arguing might be
 >> handled by an explicit user cast instead of providing overloaded
 >> operators for every possible combination.
 >>
 >
 >There's no right answer to this.  Part of the "spirit of C" that
 >C++ inherited is automatic conversion between arithmetic types
 >(the "usual arithmetic conversions"); but that creates a very
 >hard problem as Stroustrup points out in 11.1 of D&E.
 >
 >My usual choice when writing a class that acts in some way like
 >an arithmetic type is making all one-argument constructors
 >explicit so that simple conversions require explicit casts,
 >then writing all the operators I need to let the user do things
 >like Beman described in simple, unsurprising ways.  Usually,
 >all I need are templated versions of the operators for the
 >general case, then overloads or specializations for same-type
 >right-hand-side arguments where they're obviously more efficient.
 >If I find myself going in a direction that leads to a combinatorial
 >explosion of operators, I usually find that it's my design that's
 >wrong.

Yes.  Applying that to fixed point decimal, I would expect to be able to 
write expressions using at least the basic arithmetic operations without 
having to explicitly supply type information or temporaries.  It isn't the 
end of the world if I have to specify more details, but still...

--Beman