Boost logo

Boost Users :

From: John Maddock (john_at_[hidden])
Date: 2007-06-13 05:14:41


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<throw_on_error>,
> pole_error<throw_on_error>,
> overflow_error<throw_on_error>,
> evaluation_error<throw_on_error>,
> denorm_error<ignor_error>,
> underflow_error<ignor_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<integer_outside_edge>
> >
> {};
>
> ?
> 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.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net