Add utilities for std::reference_wrapper

This adds the following helpers for handling std::reference_wrapper:

• A predicate IsReferenceWrapper_v<R> for detecting if R is a std::reference_wrapper<T>.
• A helper function resolveRef for resolving references wrapped in std::reference_wrapper. For type T providing a method T::foo() this allows to transparently use resolveRef(t).foo() if t is either a plain T or a std::reference_wrapper<T>.
• A type alias ResolveRef_t<T> to determine the resolved type for T.

added feature label

The utilities can be used to implement the following pattern for function concepts C with extended interface (e.g. GridFunction):

Assume that a downstream class should work with (and capture) a function f implementing the extended function interface C. Then it can follow the standard pattern to capture f by value. To explicitly capture by reference users can pass std::ref(f). For the internally stored value f_ extended methods C::foo() can be called using resolveRef(f_).foo().

mentioned in merge request !316 (merged)

added 3 commits

• af405a95...9a44a0ec - 2 commits from branch master
• af831466 - Add utilities for std::reference_wrapper

Compare with previous version

This looks like a utility that could even be put into dune-common. It is not directly related to grid-functions but to anything that should be wrapped into a std::reference_wrapper

I also had this in mind. But since the pattern to store copies by default and provide reference support using std::reference_wrapper is mostly advertised for callbacks, I thought that we can test this approach here first. (However, I'd very much appreciate if the VTKWriter would also follow this pattern. Maybe, if someone ever does a clean re-implementation of a vtk writer, he can keep this in mind ;-))

Why is this additional IsReferneceWrapper check necessary? Wouldn't this be handled by overload-resolution? Maybe I miss something here.

You're right. I'll check. Nevertheless IsReferenceWrapper_v may be handy if you want to switch implementation block with if constexpr.

changed this line in version 3 of the diff

In fact the check was necessary to support const reference_wrapper<T>& and reference_wrapper<T>&&. But this is now treated more clearly by writing these overloads explicitly. This also adds proper treatment of r-values: reference_wrapper<T>&& is OK, but the overload for plain T&& is deleted to prevent nasal demons. Furthermore all cases are now checked in a new test.

added 2 commits

• 04df12d8 - Add utilities for std::reference_wrapper
• 26a304af - [test] Add test for resolveRef and IsReferenceWrapper_v

Compare with previous version

added 2 commits

• 94112b1b - Add utilities for std::reference_wrapper
• 684065fe - [test] Add test for resolveRef and IsReferenceWrapper_v

Compare with previous version

One could even go one step further an replace all the overloads with different const/ref qualifiern of std::reference_wrapper with just one function without reference:

template<class T>
auto& resolveRef(std::reference_wrapper<T> gf)
{
  return gf.get();
}

It has precedence over the other non-reference_wrapper overloads and handles all three cases at once. The reference_wrapper can be copied without copying the underlying wrapped element.

changed this line in version 5 of the diff

You're right, and the copy should not harm since std::reference_wrapper is trivially copyable. I implemented the change. Notice that the deleted overload for T&& is also not needed but is deliberately kept for documentation purpose and to get nicer compile errors. I also added constexpr and noexcept in the new version.

Nice.

I also added constexpr and noexcept in the new version.

Unfortunately, std::reference_wrapper::get is marked constexpr only since c++20. So, one cannot use the utility in constexpr-contexts pre-c++20. But this should not be problematic.

added 2 commits

• e66acc60 - Add utilities for std::reference_wrapper
• 29210d4a - [test] Add test for resolveRef and IsReferenceWrapper_v

Compare with previous version

No objection, merging now. If this turns out to be useful we may move it to dune-common later.

mentioned in commit d74194c9

merged

mentioned in merge request core/dune-common!1100 (merged)