Boost logo

Boost :

From: Ben Strasser (strasser.ben_at_[hidden])
Date: 2006-09-01 11:15:14


I'm having a serious problem with facets and if I don't find a solution for it
facets are definately out of the game.

Several unit types can describe the same unit. For example unit<quantity<length,
1, mass, 1> > is the same as unit<quantity<mass, 1, length, 1> > but when it
comes to types they are different.

The unit code can cope with this. facets on the other hand requier an exact type
to be able to use unit specific facets.

I only see 3 possible solutions:

1) Add a facet for each permutation of the base quantities (= length & time_
here). This is only acceptable for small quantities because the number of
combinations grows too fast. Also I don't like the idea of spamming the locale
objects full.

2) Make the quantity lists sortable and only look up the sorted versions in the
locale objects. The problem is that for this I need some smaller-as meta
function to define the order. Unfortuately I have no idea on how to generate a
default one (typeid unfortuately only return runtime objects).

Letting the user generate one is not an option. For example user 1 defines

struct mass:base_unit<mass>{};
struct length:base_unit<length>{};
template<>
struct is_smaller<mass, length>:boost::true_type{};

Now user 2 defines but knows nothing about user 1

struct time_:base_unit<time_>{};

Now user 3 defines

typedef quantity<length, 1, time, -1>velocitiy;

Peng! We're dead. user3 has to define the order between the quantities of user 1
and those of user 2. Still possible but gets very verbose and limits the
flexibility.

3) First order the base units using the exponents. If there are 2 units with the
same exponents spam all permutations.

This should work in nearly all real world examples but you can without any
problems construct senarios in which even the filling of the locales would last
ages.

Does anybody have an idea on how to solve this? A way to sort arbitrary types
would be ideal.


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