When several basis functors have to be passed to an evaluator, it's okay to pass a container type like a std::array or std::vector. All of these basis functors have to be of the same type, but using the method given above ('grokking' basis functors) it's possible to 'slot in' differently-typed basis functors - the functionality required by the evaluation code is provided by the 'grokked' functors and their inner workings remain opaque.
More...
template<typename
bf_type, int ndim>
struct vspline::multi_bf_type< bf_type, ndim >
When several basis functors have to be passed to an evaluator, it's okay to pass a container type like a std::array or std::vector. All of these basis functors have to be of the same type, but using the method given above ('grokking' basis functors) it's possible to 'slot in' differently-typed basis functors - the functionality required by the evaluation code is provided by the 'grokked' functors and their inner workings remain opaque.
For convenience, vspline provides class multi_bf_type, which inherits from std::array and passes the spline degree and, optionally, other arguments, through to the c'tors of the individual basis functors. With this construct, the c'tor signature for 'standard' b-splines (using vspline::basis_functor) can be left as it is, and the multi_bf_type holding the basis functors builds the basis functor with the given degree and derivative specification. The rather complex machinations needed to 'roll out' these arguments to the individual per-axis basis functors does not require user interaction. class multi_bf_type holds a set of basis functors, one for each dimension. While most of vspline uses vigra::TinyVectors to hold such n-dimensional objects, here we use std::array, because we need aggregate initialization, while vigra::TinyVector uses element assignment. The code is a bit tricky: the second c'tor is the one which is called from user code and takes an arbitrary argument sequence. To 'roll out' the initialization into an initializer list, we pass an index_sequence to the private first c'tor and use the expansion of the index sequence as the first value in a comma separated list of expressions, effectively discarding it. The variable argument list is expanded for each call to the basis functor's c'tor, so the unspecialized template initializes all basis functors with the same values. this is fine for cases where all basis functions are meant to do the same thing, but for b-splines, we have to consider the derivative specification, which is a per-axis argument. So for that case (see below) we need a specialization.
Definition at line 305 of file eval.h.
