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