Croutons in kdereview
Ivan Čukić
ivan.cukic at kde.org
Mon Aug 30 11:11:17 BST 2021
Hi Janet,
> Addressed most of your feedback besides the std::expected thing
Great!
> rather wait and see what that ends up being like once in an actual C++
> standard and use before modelling Result to be more like it.
Fair enough, though it is not expected that the proposal will change much in
the future (I don't remember any issues were raised with std::expected
proposal since the Prague meeting, though I might have missed something).
> Also, I don't see what advantage a member function template over the
> current use of lambdas would offer.
Invoking a std::function is as expensive as a virtual member function call
(usually implemented either as virtual dispatch-based type erasure or as
something similar). If you replace a member function taking std::function<...>
with a member function template taking the parameterised type for the function
object / invokable, you will avoid wrapping everything into a std::function
thus avoiding the performance penalty.
Another issue with std::function is that you can not store move-only lambdas
inside it (a lambda that captures a unique_ptr for example).
std::function (until we get C++23 and std::any_invocable which will further
lower the number of use-cases for std::function) should only be used if you
are storing a function object / invokable in a class or a class template that
can not be parameterised on the function object / invokable type.
Now, it is nice to see the signature of the function you need to pass to
`then` when calling it, which you lose if you switch from std::function to
a generic Fn parameter. But you can (since you're already using C++20)
restrict it with the std::invocable concept to avoid this loss of API usage
information.
Cheers,
Ivan
--
dr Ivan Čukić
ivan at cukic.co, https://cukic.co/
gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
More information about the kde-core-devel
mailing list