Allowing component clients as action return types #2184
Conversation
| HPX_ASSERT(0 != dynamic_cast< | ||
| typed_continuation<typename util::decay<Arg0>::type> * | ||
| >(this)); | ||
|
|
There was a problem hiding this comment.
Shouldn't we decay in the static_cast as well? It's about the correct dynamic type of the continuation, not how the argument is passed to it.
There was a problem hiding this comment.
Unfortunately that will not work. If Arg0 is a const&, a static_cast to the decayed type will fail compiling as the trigger_value will expect a pure rvalue.
There was a problem hiding this comment.
I am not sure I understand the issue here completely. The dynamic cast fails if the type is not decayed, that means that the dynamic type is with the decayed type, right?
On the other hand, the compilation fails when using the static_cast with the decayed type?
This sounds like there is something very fishy going on there.
There was a problem hiding this comment.
It's difficult to explain. Let's assume Arg0 is deduced as id_type const&. In this case, the dynamic_cast<Arg0>(this) would fail as this is not of type typed_continuation<id_type const&> but of type typed_continuation<id_type>. Hence the decayed argument.
At the same time, if we statically casted this to typed_continuation<id_type>, then its member function trigger_value effectively would have the signature trigger_value(id_type&&) causing compilation problems (remember, trigger_value is a virtual function and we have no way to use a forwarding reference here - which would solve the issue).
One solution would be to have another virtual function trigger_value(Result const&) which would be used by the compiler in this case. Adding this however causes issues whenever Arg0 represents a move-only type (we can't 'disable' the virtual function from the type for this case).
This code is fishy as it does a static_cast<typed_continuation<id_type const&>>(this) where this is actually a typed_continuation<id_type>. This however should not be a problem as for both types the effectively generated class is 100% identical in layout and member function signatures.
Please let me know if you have any other suggestion on how to resolve the problem.
There was a problem hiding this comment.
Shouldn't it be
typed_continuation<id_type>in the first place?
That's what I said. this points to an object of that type.
Do we really need forwarding references here? Aren't rvalue references enough?
set_lco_valueaccepts rvalue references iirc.
That does not work if the function is called with a const&, didn't I mention that?
The easiest would be if you changed the static_cast to use the decayed type yourself. That would demonstrate the problem right away.
There was a problem hiding this comment.
There was a problem hiding this comment.
I'll play with it a little bit... the sanitizer should still complain about that code.
Right, it most likely will complain. But you could tell it to ignore this instance.
There was a problem hiding this comment.
If you decay copy, everything works, here is the patch that works for me:
https://gist.github.com/sithhell/7c4f73280b236662e448b571a9218030
|
This also fixes #2182 |
hkaiser
changed the title
This fixes #2150