Operations on numbers of scalar components of systems of equations.
Problem: We are given a type that is a tk::tuple::tagged_tuple that contains an arbitrary number of std::vectors of integers. The number of vectors are fixed at compile-time (accessed via tags) but their (differing) length is only known at run-time (after parsing user input). What we need are functions that operate on this data structure and return, e.g., the total number of components in the whole system or the offset in the whole data structure for a given tag. The functions should thus be able to operate on a list of types, i.e., a double for-loop over all tags and associated vectors - one at compile-time and the other one at run-time.
Example: An example is to define storage for systems of stochastic differential equations as in walker::
Solution: Looping through a list of types is done using the Brigand's [MetaProgramming Library]. Such operations on types happen at compile-time, i.e., the code runs inside the compiler and only its result gets compiled into code to be run at run-time. Advantages are abstraction and generic code that is independent of the size and order of the tags in the tuple (and the associated vectors). Though it is not of primary concern for this data structure, this solution also generates efficient code, since part of the algorithm (for computing the offset, the total number of components, etc.) runs inside the compiler. All of this is kept generic, so it does not need to be changed when a new pair of tag and system of equations are added to the underlying tuple. Thus, the main advantage is that changing the order of the vectors in the tuple or adding new ones at arbitrary locations will not require change to client-code.
An alternative approach: Of course this could have been simply done with a purely run-time vector of vector of integers. However, that would not have allowed a tag-based access to the different systems of equations. (Sure, one can define an enum for equation indexing, but that just adds code to what is already need to be changed if a change happens to the underlying data structure.) As a consequence, a component in a vector of vector would have had to be accessed as something like, ncomps, which is more error-prone to read than ncomps< tag::dirichlet >( 3 ). Furthermore, that design would have resulted in double-loops at run-time, instead of letting the compiler loop over the types at compile-time and do the run-time loops only for what is only known at run-time. Additionally, and most importantly, any time a new system is introduced (or the order is changed), all client-code would have to be changed.