gcc 3.2 doesn't compile this code (works with gcc 3.3 and up):
#include <boost/math/distributions.hpp> int main() { boost::math::students_t_distribution<double> dist(1.); dist.find_degrees_of_freedom(1.,2.,3.,4.,5.); return 0; }
Reduced:
template <unsigned N, class T, class V> inline V evaluate_polynomial(const T(&a)[N], const V& val)
I will be wrong linguistically, but I hate the definition of 'a' here. What is it to be? I assume it is a reference to an array, I guess. But then why not just take a reference to the first element and a count, or use a range (pointer + size)?
Sorry, I don't know anything about boost/math/distributions. But this kind of non-problem being a problem is in fact, a problem.
If 'a' is just an array, say it like it is. Why make a fuss?
Because it makes a difference, both for maintenance and performance: * For maintenance, we're much less likely to introduce subtle bugs if the function "knows" how big the array is, rather than us having to specify the size at the call site, as well as at the definition of the array. * For performance: for small arrays of known size we can omit the for-loop and just evaluate the polynomial using near-optimal code. Since polynomial/rational function evaluation is often the pinch-point for functions implemented using rational-approximations it makes sense to optimize this as far as possible even if it only gains us 20-30%. We could of course code the polynomial evaluation separately each time it's needed - and without a separate function - that's what most other similar libraries do, but as well as being untidy, it precludes library wide improvements to this core function, unless of course you change every usage :-( As for the original problem: I'm afraid I don't have an obvious workaround that springs to mind, I will try and install an early gcc version to test with, but last time I tried you can't even *build* gcc-3.x on recent Linux builds :-( John.