The idea of the FieldTraits class is to provide
the field_type and real_type of various types
representing numbers, vectors, ... .
So far there was a default implementation
template<class T>
struct FieldTraits
{
typedef T field_type;
typedef T real_type;
};This does not make much sense, for types that do not
represent numbers. The patch ensures that the default
implementation does only provide the typedefs if
Dune::IsNumber<T> is true and that it is empty
otherwise.
This also fixes a seemingly unrelated issue: If you
defined operator*(T,T) and dot(T,T) for your own
type (or concept) T, then dot is ambiguous,
because there's a very greedy implementation in
dotproduct.hh.
Here is a list (thanks to @simon.praetorius for the collection...) of wrong usage/missing specializations which must be fixed before merging:
dune/istl/multitypeblockvector.hh:80 if no types are given or there is no common field-type of all the components, set as field_type the fallback Dune::Std::nonesuch. This results in an error, but occurs in recursive implementations because the fallback field_type is used to define a real_type. This is not correct and a corresponding nonsuch should also be defined as real_type instead. (dune-istl!480 (merged))dune/istl/multiindex.hh: a type parametrized with Field type. This should be the definition in FieldTraits (dune-localfunctions!217 (merged))dune/istl/tensor.hh: The LFETensor is a container type, thus should recursively define the FieldTraits. Also, there is the class Derivative defining also a field type. (dune-localfunctions!217 (merged))dune/common/debugalign.hh: Need specialization for IsNumber for AlignedNumber
SimdArray is not detected as a valid field type anymore.dune/common/fvector.hh:323: Constructor leads to second order substitution failures and thus a compile error when compiling dune-spgrid testsDune::FieldTraits<Vc_1::SimdArray<...>> needs a specialization.