David Abrahams wrote:
The main disadvantage I've noticed at present, is that the mangled names of the policy class - and therefore all the special functions etc - are *very* long.
Why not make it allowable to use derivation:
struct fast_quantile_policy : policy< // Set error handling: domain_error
, pole_error , overflow_error , evaluation_error , denorm_error , underflow_error , // calculate to 8 decimal digits internally digits10<8>, // don't promote double->long double for accuracy promote_double<false>, // Integer quantiles return the "outside edge": // below the real value for lower critical values, // above it for upper critical values, so that the // area inside contains *at least* the requested coverage: discrete_quantile > {}; ? That will keep your type names under control.
Interesting idea. Actually as far as the code internals are concerned the only thing that matters are the member typedefs of the policy class used, so this should "just work".... but one of things I was planning on doing is "normalising" the policy class passed to the function: basically decompose it and then recompose in a particular order: that way if the same function is called with different policy types that actually name the same policies, then internally only one template gets instantiated and we reduce code bloat. The same mechanism can stip out policies that have no relevence to the function being called, again potentially reducing code bloat. At present I don't see a way to combine that with your inheritance mechanism. I also need to be able to inject certain computed policies into the policy object when it get's normalised (basically a combination of the existing policy and it's combination with the actual real-number type being used for the computation). I do have a Boost.Format based mechanism to create nicely formatted function names though - and yes only invoked when needed - so I guess the question is whether these long mangled names have any other consequences: compile and or link time for example? Thanks, John.