Felix Gruber authored 9 years ago and Christoph Grüninger committed 9 years ago

I still don't understand why, but GCC was spilling deprecation warnings
for Dune::enable_if even if we were only using std::enable_if.

Thus I removed the deprecation of the enable_if struct and only
deprecate the type within. That should still be enough as this
deprecation warning gets triggered when enable_if is used to aid in
overload resolution and the boolean parameter of enable_if is true.

Felix Gruber authored 9 years ago and Christoph Grüninger committed 9 years ago

My previous wrapper implementation around std::enable_if didn't work
when B was false, as type was then defined to a type that was SFINAEd
away.

Felix Gruber authored 9 years ago and Christoph Grüninger committed 9 years ago

Using inheritance for the deprecated wrapper class unfortunately only
worked on GCC, so we had to define the type or value of the type trait
explicitly to deprecate it.

Felix Gruber authored 9 years ago and Christoph Grüninger committed 9 years ago

Since we cannot deprecate using statements, I changed all using
statements for std type traits into thin wrapper classes that I then
deprecated.

Felix Gruber authored 9 years ago and Christoph Grüninger committed 9 years ago

This is not needed anymore, as the testet type traits are directly
imported from std:: and can thus be assumed to be correct.

Felix Gruber authored 9 years ago and Christoph Grüninger committed 9 years ago

Is ConstVolatileTraits still used anywhere? I would propose to
deprecate it and replace it with std::is_volatile, std::is_const,
std::remove_cv, etc.

Felix Gruber authored 9 years ago and Christoph Grüninger committed 9 years ago

They can be replaced by std::is_base_of, std::is_const and
std::is_volatile, respectively.

Felix Gruber authored 9 years ago and Christoph Grüninger committed 9 years ago

Now that we require a C++11-compliant compiler, we can use
the std type traits to construct our own.

Slightly improve warning

Previously, the following piece of code would compile and only
only predictable fail at runtime with assertions enabled.

  Dune::FieldMatrix<double, 2, 3> A;
  // populate A

  Dune::FieldMatrix<double, 3, 2> B_bad;
  // populate B_bad
  A.rightmultiply(B_bad);

It now fails to compile.

Previously, the following piece of code would compile but then enter a
loop, typically leading to a segmentation fault

  Dune::FieldMatrix<double, 2, 3> A;
  // populate A

  Dune::DynamicMatrix<double> B_good(3, 3);
  // populate B_good
  A.rightmultiply(B_good);

This would also happen for the following illegal extension of the above code

  Dune::FieldMatrix<double, 3, 2> B_bad;
  // populate B_bad
  A.rightmultiply(B_bad);

The former now works as expected while the latter fails an assertion.

added void_t (incl. voider-hack for gcc), and template aliases real_t and field_t for convenient access of T::real_type, T::field_type

added void_t (incl. voider-hack for gcc), and template aliases real_t and field_t for convenient access of T::real_type, T::field_type