-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add sharded<>::invoke_on_all()
const overload
#2278
Comments
Cc @tchaikov |
There are several options what invoke_on_...() can try to invoke. So far only non-const and non-mutable callables are in use and it works. If calling it with mutable lambdas, it used to fail compilation, but previous patch fixed it, so here's the test. It also makes sense to support calling it on const sharded<> object (with the lambda accepting const service reference), but it's not that simple (see scylladb#2278) Signed-off-by: Pavel Emelyanov <[email protected]>
There are several options what invoke_on_...() can try to invoke. So far only non-const and non-mutable callables are in use and it works. If calling it with mutable lambdas, it used to fail compilation, but previous patch fixed it, so here's the test. It also makes sense to support calling it on const sharded<> object (with the lambda accepting const service reference), but it's not that simple (see scylladb#2278) Signed-off-by: Pavel Emelyanov <[email protected]>
There are several options what invoke_on_...() can try to invoke. So far only non-const and non-mutable callables are in use and it works. If calling it with mutable lambdas, it used to fail compilation, but previous patch fixed it, so here's the test. It also makes sense to support calling it on const sharded<> object (with the lambda accepting const service reference), but it's not that simple (see scylladb#2278) Signed-off-by: Pavel Emelyanov <[email protected]>
There are several options what invoke_on_...() can try to invoke. So far only non-const and non-mutable callables are in use and it works. If calling it with mutable lambdas, it used to fail compilation, but previous patch fixed it, so here's the test. It also makes sense to support calling it on const sharded<> object (with the lambda accepting const service reference), but it's not that simple (see scylladb#2278) Signed-off-by: Pavel Emelyanov <[email protected]>
i was staring at this for a while. and was checking https://eel.is/c++draft/over.match.funcs . but still cannot figure out a satisfying explanation.. |
if you replace the second template <typename Fn>
requires std::invocable<Fn, T&>
void call(Fn fn) const {
fmt::print("const call\n");
fn(_x);
} |
From my perspective no, the 2nd overload starts accepting fn(T&) instead of fn(const T&) which |
There are several options what invoke_on_...() can try to invoke. So far only non-const and non-mutable callables are in use and it works. If calling it with mutable lambdas, it used to fail compilation, but previous patch fixed it, so here's the test. It also makes sense to support calling it on const sharded<> object (with the lambda accepting const service reference), but it's not that simple (see scylladb#2278) Signed-off-by: Pavel Emelyanov <[email protected]>
The map-reduce-s have it, why not have for invoke_on_all()? However, it looks like it's going to break compilation
Consider this
Note that there are two
wrapper::call()
overloads -- const and non-const one, just like we want forsharded::invoke_on_all
.If compiled and run we'll see
which is expected -- no
const
is involved at all. However, if removing thefoo::fn() const
overload, the whole thing will fail to compile withRespectively, adding
sharded::invoke_on_all() const
will fail compilation of any non-const calls tosharded<S>::invoke_on_all(&S::method)
for S's that don't haveS::method() const
-sThe text was updated successfully, but these errors were encountered: