Boost logo

Boost :

From: Dan W. (danw_at_[hidden])
Date: 2004-01-08 16:19:08

Matthias Schabel wrote:
> The only problem with having a non-class conversion function is that
> there will be N^2 overloaded functions for N different units. That
> makes extensibility a problem : for example, if the library itself
> defines a few length units (pseudocode alert)
> then if someone decides they want to use rods, they're going to have to
> add 4*3-3*2 = 6 new functions. Then the next person who needs fathoms
> will have to add the 2(N-1) = 8 more functions, etc... Maybe the
> solution would be to have a default converter which looks something like

I think you could have your cake and eat it too: You could have an
internal absolute reference, as long as

A) It uses compile-time unlimited precision types (thinking of Plank's
B) It is compile-time (mpl?) and generates whatever converters are
needed, mindful of precision issues.
C) It is internal to the library, --i.e.: as a user, I'd never suspect
its existence. Which means, I declare furlongs as const * cubits, and
the conversion generator reads that and generates conversions to or from
internal absolutes, as step 1, and later generates conversions to/from
inches, if I *use* inches in the program, that's fine with me.

Boost list run by bdawes at, gregod at, cpdaniel at, john at