> It might be as well to note that this functionality [integral
> and floating point promotions] is provided by Boost.Typeof,
> however Boost.Typeof can cause very slow compile times.

This should not be the case for such simple types as integrals and floating
points, though. In such case the main overhead doesn't come from type
encoding/decoding, but rather from the need to pass non-used items through
the function boundaries, which is a mauch smaller overhead. Also, it should
be easy to factor out yet another macro where one could provide the size of
the vector used for encoding (unfortunately, this is a pre-processor
constant, and can't be figured out by the typeof library based on the actual
type). If this size is set to one, I don't see _any_ overhead.