Make FieldTraits less greedy
- Jun 02, 2024
-
-
Simon Praetorius authored -
This overload is explicitly for type that do not implement `FieldTraits` but are still convertible to the stored scalar type. This is e.g. the case for `GMPField` expression templates.
-
This is a bugfix. By not defining the traits class it implicitly used the default implementation which did not make any sense at all. BTW: It's a pitty that we have to define two traits classes for any `DenseVector` implementation `DenseMatVecTraits` and `FieldTraits`. But fixing this is another issue.
-
This may be helful when constraining overloads, because any overload incorporation FieldTraits<T>::field_type in some enable_if check will be rules out due to SFINAE. This can be circumvented using FieldTraitsEmpty which would e.g. catch GMPField expression templatestemplates.
-
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 ```cpp 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`.
-
