Mixing
Named, static dispatching with std::variant
I need to fill in some template magic to make the following code snippet to work.
The problem is that I want to be able to define a visitor class for std::variant with named static methods accepting two arguments. How can I fill in Applicator::apply() to make the dispatching work?
struct EventA {};
struct EventB {};
struct EventC {};
using Event = std::variant<EventA, EventB, EventC>;
struct Visitor {
enum class LastEvent { None, A, B, C };
struct State {
LastEvent last_event = LastEvent::None;
};
static State apply(State s, EventA e) { return State{LastEvent::A}; }
static State apply(State s, EventB e) { return State{LastEvent::B}; }
};
template <typename Visitor> struct Applicator {
static State apply(State s, Event e) {
/*** Start of pseudo code ***/
if (Visitor can apply) {
return Visitor::apply(s, e);
}
/*** End of pseudo code ***/
// Else, don't update state state
return s;
}
};
int main() {
// Handled by visitor
State s1 = Applicator<Visitor>::apply(State{}, EventA{});
assert(s1.last_event == Visitor::LastEvent::A);
// Handled by visitor
State s2 = Applicator<Visitor>::apply(State{}, EventB{});
assert(s2.last_event == Visitor::LastEvent::B);
// NOT handled by visitor
State s3 = Applicator<Visitor>::apply(State{}, EventC{});
assert(s3.last_event == Visitor::LastEvent::None);
}
c++ c++17
edited Jan 4 at 10:17
Deduplicator
34.3k64888
asked Jan 4 at 9:46
aerkenemesisaerkenemesis
489313
add a comment |
I need to fill in some template magic to make the following code snippet to work.
The problem is that I want to be able to define a visitor class for std::variant with named static methods accepting two arguments. How can I fill in Applicator::apply() to make the dispatching work?
struct EventA {};
struct EventB {};
struct EventC {};
using Event = std::variant<EventA, EventB, EventC>;
struct Visitor {
enum class LastEvent { None, A, B, C };
struct State {
LastEvent last_event = LastEvent::None;
};
static State apply(State s, EventA e) { return State{LastEvent::A}; }
static State apply(State s, EventB e) { return State{LastEvent::B}; }
};
template <typename Visitor> struct Applicator {
static State apply(State s, Event e) {
/*** Start of pseudo code ***/
if (Visitor can apply) {
return Visitor::apply(s, e);
}
/*** End of pseudo code ***/
// Else, don't update state state
return s;
}
};
int main() {
// Handled by visitor
State s1 = Applicator<Visitor>::apply(State{}, EventA{});
assert(s1.last_event == Visitor::LastEvent::A);
// Handled by visitor
State s2 = Applicator<Visitor>::apply(State{}, EventB{});
assert(s2.last_event == Visitor::LastEvent::B);
// NOT handled by visitor
State s3 = Applicator<Visitor>::apply(State{}, EventC{});
assert(s3.last_event == Visitor::LastEvent::None);
}
c++ c++17
edited Jan 4 at 10:17
Deduplicator
34.3k64888
asked Jan 4 at 9:46
aerkenemesisaerkenemesis
489313
1
Aside: isStatereally meant to be a member ofVisitor?
– Caleth
Jan 4 at 11:12
@Caleth yes, the Visitor is just used as a namespace to handle different kinds of events so it should encapsulate both the state and the operations that operates on that state. This is a very contrived example though.
– aerkenemesis
Jan 4 at 11:28
1
then it should betypename Visitor::StateinApplicator(orVisitor::Stateif you drop the template parameter that shadows the class)
– Caleth
Jan 4 at 11:31
Well I didn't try compiling it since it contains pseudo code, as I said - it is a contrived example.
– aerkenemesis
Jan 4 at 12:47
add a comment |
I need to fill in some template magic to make the following code snippet to work.
The problem is that I want to be able to define a visitor class for std::variant with named static methods accepting two arguments. How can I fill in Applicator::apply() to make the dispatching work?
struct EventA {};
struct EventB {};
struct EventC {};
using Event = std::variant<EventA, EventB, EventC>;
struct Visitor {
enum class LastEvent { None, A, B, C };
struct State {
LastEvent last_event = LastEvent::None;
};
static State apply(State s, EventA e) { return State{LastEvent::A}; }
static State apply(State s, EventB e) { return State{LastEvent::B}; }
};
template <typename Visitor> struct Applicator {
static State apply(State s, Event e) {
/*** Start of pseudo code ***/
if (Visitor can apply) {
return Visitor::apply(s, e);
}
/*** End of pseudo code ***/
// Else, don't update state state
return s;
}
};
int main() {
// Handled by visitor
State s1 = Applicator<Visitor>::apply(State{}, EventA{});
assert(s1.last_event == Visitor::LastEvent::A);
// Handled by visitor
State s2 = Applicator<Visitor>::apply(State{}, EventB{});
assert(s2.last_event == Visitor::LastEvent::B);
// NOT handled by visitor
State s3 = Applicator<Visitor>::apply(State{}, EventC{});
assert(s3.last_event == Visitor::LastEvent::None);
}
c++ c++17
edited Jan 4 at 10:17
Deduplicator
34.3k64888
asked Jan 4 at 9:46
aerkenemesisaerkenemesis
489313
I need to fill in some template magic to make the following code snippet to work.
The problem is that I want to be able to define a visitor class for std::variant with named static methods accepting two arguments. How can I fill in Applicator::apply() to make the dispatching work?
struct EventA {};
struct EventB {};
struct EventC {};
using Event = std::variant<EventA, EventB, EventC>;
struct Visitor {
enum class LastEvent { None, A, B, C };
struct State {
LastEvent last_event = LastEvent::None;
};
static State apply(State s, EventA e) { return State{LastEvent::A}; }
static State apply(State s, EventB e) { return State{LastEvent::B}; }
};
template <typename Visitor> struct Applicator {
static State apply(State s, Event e) {
/*** Start of pseudo code ***/
if (Visitor can apply) {
return Visitor::apply(s, e);
}
/*** End of pseudo code ***/
// Else, don't update state state
return s;
}
};
int main() {
// Handled by visitor
State s1 = Applicator<Visitor>::apply(State{}, EventA{});
assert(s1.last_event == Visitor::LastEvent::A);
// Handled by visitor
State s2 = Applicator<Visitor>::apply(State{}, EventB{});
assert(s2.last_event == Visitor::LastEvent::B);
// NOT handled by visitor
State s3 = Applicator<Visitor>::apply(State{}, EventC{});
assert(s3.last_event == Visitor::LastEvent::None);
}
c++ c++17
c++ c++17
edited Jan 4 at 10:17
Deduplicator
34.3k64888
asked Jan 4 at 9:46
aerkenemesisaerkenemesis
489313
edited Jan 4 at 10:17
Deduplicator
34.3k64888
asked Jan 4 at 9:46
aerkenemesisaerkenemesis
489313
edited Jan 4 at 10:17
Deduplicator
34.3k64888
edited Jan 4 at 10:17
Deduplicator
34.3k64888
edited Jan 4 at 10:17
Deduplicator
34.3k64888
34.3k64888
asked Jan 4 at 9:46
aerkenemesisaerkenemesis
489313
asked Jan 4 at 9:46
aerkenemesisaerkenemesis
489313
asked Jan 4 at 9:46
aerkenemesisaerkenemesis
489313
489313
1
Aside: isStatereally meant to be a member ofVisitor?
– Caleth
Jan 4 at 11:12
@Caleth yes, the Visitor is just used as a namespace to handle different kinds of events so it should encapsulate both the state and the operations that operates on that state. This is a very contrived example though.
– aerkenemesis
Jan 4 at 11:28
1
then it should betypename Visitor::StateinApplicator(orVisitor::Stateif you drop the template parameter that shadows the class)
– Caleth
Jan 4 at 11:31
Well I didn't try compiling it since it contains pseudo code, as I said - it is a contrived example.
– aerkenemesis
Jan 4 at 12:47
add a comment |
1
Aside: isStatereally meant to be a member ofVisitor?
– Caleth
Jan 4 at 11:12
@Caleth yes, the Visitor is just used as a namespace to handle different kinds of events so it should encapsulate both the state and the operations that operates on that state. This is a very contrived example though.
– aerkenemesis
Jan 4 at 11:28
1
then it should betypename Visitor::StateinApplicator(orVisitor::Stateif you drop the template parameter that shadows the class)
– Caleth
Jan 4 at 11:31
Well I didn't try compiling it since it contains pseudo code, as I said - it is a contrived example.
– aerkenemesis
Jan 4 at 12:47
1
1
Aside: is
State really meant to be a member of Visitor?– Caleth
Jan 4 at 11:12
Aside: is
State really meant to be a member of Visitor?– Caleth
Jan 4 at 11:12
@Caleth yes, the Visitor is just used as a namespace to handle different kinds of events so it should encapsulate both the state and the operations that operates on that state. This is a very contrived example though.
– aerkenemesis
Jan 4 at 11:28
@Caleth yes, the Visitor is just used as a namespace to handle different kinds of events so it should encapsulate both the state and the operations that operates on that state. This is a very contrived example though.
– aerkenemesis
Jan 4 at 11:28
1
1
then it should be
typename Visitor::State in Applicator (or Visitor::State if you drop the template parameter that shadows the class)– Caleth
Jan 4 at 11:31
then it should be
typename Visitor::State in Applicator (or Visitor::State if you drop the template parameter that shadows the class)– Caleth
Jan 4 at 11:31
Well I didn't try compiling it since it contains pseudo code, as I said - it is a contrived example.
– aerkenemesis
Jan 4 at 12:47
Well I didn't try compiling it since it contains pseudo code, as I said - it is a contrived example.
– aerkenemesis
Jan 4 at 12:47
add a comment |
4 Answers
4
active
oldest
votes
Another solution:
using State = Visitor::State;
template<class Visitor>
struct VisitorProxy {
State s;
template<class E>
auto operator()(E const& e) -> decltype(Visitor::apply(s, e)) {
return Visitor::apply(s, e);
}
template<class E>
State operator()(E const&) const {
return s;
}
};
template <typename Visitor> struct Applicator {
static State apply(State s, Event e) {
VisitorProxy<Visitor> p{s};
return std::visit(p, e);
}
};
answered Jan 4 at 10:39
Maxim EgorushkinMaxim Egorushkin
86.1k11100183
2
Priorizing onconst... Now that's a clever trick I didn't see before. Neat!
– Quentin
Jan 4 at 10:42
1
Thank you! This worked perfectly. I didn't know you could do SFINAE on the return type like that :)
– aerkenemesis
Jan 4 at 11:26
add a comment |
Using the now quite common overloaded class template trick (And Maxim's trick to order the lambdas based on the constness of their operator()) to create a SFINAE-capable functor modeling the logic you're lookig for:
template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;
// ...
template <typename Visitor> struct Applicator {
static typename Visitor::State apply(typename Visitor::State s, Event e) {
return std::visit(overloaded{
[&s](auto e) mutable -> decltype(Visitor::apply(s, e)) { return Visitor::apply(s, e); },
[&s](auto) { return s; }
}, e);
}
};
Note that this ICEs all versions of Clang I've tested on Wandbox, but I haven't found a workaround. Perfect forwarding is left as an exercise to the reader :)
answered Jan 4 at 10:37
QuentinQuentin
45.5k586141
1
Is it not UB to passEventinto...?
– Maxim Egorushkin
Jan 4 at 10:42
1
@MaximEgorushkin I thought it was okay, but apparently it is implementation-defined... I'll pinch yourconst-based ordering instead, much safer ;)
– Quentin
Jan 4 at 10:45
Why is it implementation defined to pass Event into ...?
– Kilian
Jan 4 at 11:35
1
@Kilian because varargs are a compatibility feature with C source and haven't been adapted much. For example, on MSVC they will perform the equivalent of astd::memcpy, without calling constructors or destructors.
– Quentin
Jan 4 at 12:24
add a comment |
If the Visitor can always apply, then the code can be as simple as
return std::visit([&](auto e) { return Visitor::apply(s, e); }, e);
But since Visitor cannot always apply, we need to use SFINAE, which requires a set of overloaded function templates. The function templates can be defined like this:
template<class EventType>
static auto applyHelper(State s, EventType e, int)
-> decltype(Visitor::apply(s, e)) // only enabled if Visitor::apply(s, e) is a valid expression
{
return Visitor::apply(s, e);
}
template<class EventType>
static State applyHelper(State s, EventType e, long) // long gives a lower precedence
// in overload resolution when argument is 0
{
return s;
}
Then the implementation of Applicator::apply can be
static State apply(State s, Event e) {
return std::visit([&](auto e) { return applyHelper(s, e, 0); }, e);
}
answered Jan 4 at 10:46
cpplearnercpplearner
4,99021936
add a comment |
Well, std::is_invocable_r looks like the tool of choice.
Unfortunately, you would have to get the type of the right overload, which would completely defeat the purpose.
Instead, go one step back and use std::is_detected from library fundamentals TS v2 or equivalent and a template:
template <class... Xs>
using can_Visitor_apply = decltype(Visitor::apply(std::declval<Xs>()...));
if constexpr(std::is_detected_convertible<State, can_Visitor_apply, State&, Event&>())
return Visitor::apply(s, e);
The advantage is that you have a compile-time-constant to hang arbitrary decisions on. The disadvantage is not (yet) having a function which you can simply just call and forget about it.
answered Jan 4 at 10:44
DeduplicatorDeduplicator
34.3k64888
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54036439%2fnamed-static-dispatching-with-stdvariant%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Another solution:
using State = Visitor::State;
template<class Visitor>
struct VisitorProxy {
State s;
template<class E>
auto operator()(E const& e) -> decltype(Visitor::apply(s, e)) {
return Visitor::apply(s, e);
}
template<class E>
State operator()(E const&) const {
return s;
}
};
template <typename Visitor> struct Applicator {
static State apply(State s, Event e) {
VisitorProxy<Visitor> p{s};
return std::visit(p, e);
}
};
answered Jan 4 at 10:39
Maxim EgorushkinMaxim Egorushkin
86.1k11100183
2
Priorizing onconst... Now that's a clever trick I didn't see before. Neat!
– Quentin
Jan 4 at 10:42
1
Thank you! This worked perfectly. I didn't know you could do SFINAE on the return type like that :)
– aerkenemesis
Jan 4 at 11:26
add a comment |
Another solution:
using State = Visitor::State;
template<class Visitor>
struct VisitorProxy {
State s;
template<class E>
auto operator()(E const& e) -> decltype(Visitor::apply(s, e)) {
return Visitor::apply(s, e);
}
template<class E>
State operator()(E const&) const {
return s;
}
};
template <typename Visitor> struct Applicator {
static State apply(State s, Event e) {
VisitorProxy<Visitor> p{s};
return std::visit(p, e);
}
};
answered Jan 4 at 10:39
Maxim EgorushkinMaxim Egorushkin
86.1k11100183
2
Priorizing onconst... Now that's a clever trick I didn't see before. Neat!
– Quentin
Jan 4 at 10:42
1
Thank you! This worked perfectly. I didn't know you could do SFINAE on the return type like that :)
– aerkenemesis
Jan 4 at 11:26
add a comment |
Another solution:
using State = Visitor::State;
template<class Visitor>
struct VisitorProxy {
State s;
template<class E>
auto operator()(E const& e) -> decltype(Visitor::apply(s, e)) {
return Visitor::apply(s, e);
}
template<class E>
State operator()(E const&) const {
return s;
}
};
template <typename Visitor> struct Applicator {
static State apply(State s, Event e) {
VisitorProxy<Visitor> p{s};
return std::visit(p, e);
}
};
answered Jan 4 at 10:39
Maxim EgorushkinMaxim Egorushkin
86.1k11100183
Another solution:
using State = Visitor::State;
template<class Visitor>
struct VisitorProxy {
State s;
template<class E>
auto operator()(E const& e) -> decltype(Visitor::apply(s, e)) {
return Visitor::apply(s, e);
}
template<class E>
State operator()(E const&) const {
return s;
}
};
template <typename Visitor> struct Applicator {
static State apply(State s, Event e) {
VisitorProxy<Visitor> p{s};
return std::visit(p, e);
}
};
answered Jan 4 at 10:39
Maxim EgorushkinMaxim Egorushkin
86.1k11100183
answered Jan 4 at 10:39
Maxim EgorushkinMaxim Egorushkin
86.1k11100183
answered Jan 4 at 10:39
Maxim EgorushkinMaxim Egorushkin
86.1k11100183
answered Jan 4 at 10:39
Maxim EgorushkinMaxim Egorushkin
86.1k11100183
86.1k11100183
2
Priorizing onconst... Now that's a clever trick I didn't see before. Neat!
– Quentin
Jan 4 at 10:42
1
Thank you! This worked perfectly. I didn't know you could do SFINAE on the return type like that :)
– aerkenemesis
Jan 4 at 11:26
add a comment |
2
Priorizing onconst... Now that's a clever trick I didn't see before. Neat!
– Quentin
Jan 4 at 10:42
1
Thank you! This worked perfectly. I didn't know you could do SFINAE on the return type like that :)
– aerkenemesis
Jan 4 at 11:26
2
2
Priorizing on
const... Now that's a clever trick I didn't see before. Neat!– Quentin
Jan 4 at 10:42
Priorizing on
const... Now that's a clever trick I didn't see before. Neat!– Quentin
Jan 4 at 10:42
1
1
Thank you! This worked perfectly. I didn't know you could do SFINAE on the return type like that :)
– aerkenemesis
Jan 4 at 11:26
Thank you! This worked perfectly. I didn't know you could do SFINAE on the return type like that :)
– aerkenemesis
Jan 4 at 11:26
add a comment |
Using the now quite common overloaded class template trick (And Maxim's trick to order the lambdas based on the constness of their operator()) to create a SFINAE-capable functor modeling the logic you're lookig for:
template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;
// ...
template <typename Visitor> struct Applicator {
static typename Visitor::State apply(typename Visitor::State s, Event e) {
return std::visit(overloaded{
[&s](auto e) mutable -> decltype(Visitor::apply(s, e)) { return Visitor::apply(s, e); },
[&s](auto) { return s; }
}, e);
}
};
Note that this ICEs all versions of Clang I've tested on Wandbox, but I haven't found a workaround. Perfect forwarding is left as an exercise to the reader :)
answered Jan 4 at 10:37
QuentinQuentin
45.5k586141
1
Is it not UB to passEventinto...?
– Maxim Egorushkin
Jan 4 at 10:42
1
@MaximEgorushkin I thought it was okay, but apparently it is implementation-defined... I'll pinch yourconst-based ordering instead, much safer ;)
– Quentin
Jan 4 at 10:45
Why is it implementation defined to pass Event into ...?
– Kilian
Jan 4 at 11:35
1
@Kilian because varargs are a compatibility feature with C source and haven't been adapted much. For example, on MSVC they will perform the equivalent of astd::memcpy, without calling constructors or destructors.
– Quentin
Jan 4 at 12:24
add a comment |
Using the now quite common overloaded class template trick (And Maxim's trick to order the lambdas based on the constness of their operator()) to create a SFINAE-capable functor modeling the logic you're lookig for:
template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;
// ...
template <typename Visitor> struct Applicator {
static typename Visitor::State apply(typename Visitor::State s, Event e) {
return std::visit(overloaded{
[&s](auto e) mutable -> decltype(Visitor::apply(s, e)) { return Visitor::apply(s, e); },
[&s](auto) { return s; }
}, e);
}
};
Note that this ICEs all versions of Clang I've tested on Wandbox, but I haven't found a workaround. Perfect forwarding is left as an exercise to the reader :)
answered Jan 4 at 10:37
QuentinQuentin
45.5k586141
1
Is it not UB to passEventinto...?
– Maxim Egorushkin
Jan 4 at 10:42
1
@MaximEgorushkin I thought it was okay, but apparently it is implementation-defined... I'll pinch yourconst-based ordering instead, much safer ;)
– Quentin
Jan 4 at 10:45
Why is it implementation defined to pass Event into ...?
– Kilian
Jan 4 at 11:35
1
@Kilian because varargs are a compatibility feature with C source and haven't been adapted much. For example, on MSVC they will perform the equivalent of astd::memcpy, without calling constructors or destructors.
– Quentin
Jan 4 at 12:24
add a comment |
Using the now quite common overloaded class template trick (And Maxim's trick to order the lambdas based on the constness of their operator()) to create a SFINAE-capable functor modeling the logic you're lookig for:
template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;
// ...
template <typename Visitor> struct Applicator {
static typename Visitor::State apply(typename Visitor::State s, Event e) {
return std::visit(overloaded{
[&s](auto e) mutable -> decltype(Visitor::apply(s, e)) { return Visitor::apply(s, e); },
[&s](auto) { return s; }
}, e);
}
};
Note that this ICEs all versions of Clang I've tested on Wandbox, but I haven't found a workaround. Perfect forwarding is left as an exercise to the reader :)
answered Jan 4 at 10:37
QuentinQuentin
45.5k586141
Using the now quite common overloaded class template trick (And Maxim's trick to order the lambdas based on the constness of their operator()) to create a SFINAE-capable functor modeling the logic you're lookig for:
template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;
// ...
template <typename Visitor> struct Applicator {
static typename Visitor::State apply(typename Visitor::State s, Event e) {
return std::visit(overloaded{
[&s](auto e) mutable -> decltype(Visitor::apply(s, e)) { return Visitor::apply(s, e); },
[&s](auto) { return s; }
}, e);
}
};
Note that this ICEs all versions of Clang I've tested on Wandbox, but I haven't found a workaround. Perfect forwarding is left as an exercise to the reader :)
answered Jan 4 at 10:37
QuentinQuentin
45.5k586141
edited Jan 4 at 10:47
answered Jan 4 at 10:37
QuentinQuentin
45.5k586141
answered Jan 4 at 10:37
QuentinQuentin
45.5k586141
answered Jan 4 at 10:37
QuentinQuentin
45.5k586141
45.5k586141
1
Is it not UB to passEventinto...?
– Maxim Egorushkin
Jan 4 at 10:42
1
@MaximEgorushkin I thought it was okay, but apparently it is implementation-defined... I'll pinch yourconst-based ordering instead, much safer ;)
– Quentin
Jan 4 at 10:45
Why is it implementation defined to pass Event into ...?
– Kilian
Jan 4 at 11:35
1
@Kilian because varargs are a compatibility feature with C source and haven't been adapted much. For example, on MSVC they will perform the equivalent of astd::memcpy, without calling constructors or destructors.
– Quentin
Jan 4 at 12:24
add a comment |
1
Is it not UB to passEventinto...?
– Maxim Egorushkin
Jan 4 at 10:42
1
@MaximEgorushkin I thought it was okay, but apparently it is implementation-defined... I'll pinch yourconst-based ordering instead, much safer ;)
– Quentin
Jan 4 at 10:45
Why is it implementation defined to pass Event into ...?
– Kilian
Jan 4 at 11:35
1
@Kilian because varargs are a compatibility feature with C source and haven't been adapted much. For example, on MSVC they will perform the equivalent of astd::memcpy, without calling constructors or destructors.
– Quentin
Jan 4 at 12:24
1
1
Is it not UB to pass
Event into ...?– Maxim Egorushkin
Jan 4 at 10:42
Is it not UB to pass
Event into ...?– Maxim Egorushkin
Jan 4 at 10:42
1
1
@MaximEgorushkin I thought it was okay, but apparently it is implementation-defined... I'll pinch your
const-based ordering instead, much safer ;)– Quentin
Jan 4 at 10:45
@MaximEgorushkin I thought it was okay, but apparently it is implementation-defined... I'll pinch your
const-based ordering instead, much safer ;)– Quentin
Jan 4 at 10:45
Why is it implementation defined to pass Event into ...?
– Kilian
Jan 4 at 11:35
Why is it implementation defined to pass Event into ...?
– Kilian
Jan 4 at 11:35
1
1
@Kilian because varargs are a compatibility feature with C source and haven't been adapted much. For example, on MSVC they will perform the equivalent of a
std::memcpy, without calling constructors or destructors.– Quentin
Jan 4 at 12:24
@Kilian because varargs are a compatibility feature with C source and haven't been adapted much. For example, on MSVC they will perform the equivalent of a
std::memcpy, without calling constructors or destructors.– Quentin
Jan 4 at 12:24
add a comment |
If the Visitor can always apply, then the code can be as simple as
return std::visit([&](auto e) { return Visitor::apply(s, e); }, e);
But since Visitor cannot always apply, we need to use SFINAE, which requires a set of overloaded function templates. The function templates can be defined like this:
template<class EventType>
static auto applyHelper(State s, EventType e, int)
-> decltype(Visitor::apply(s, e)) // only enabled if Visitor::apply(s, e) is a valid expression
{
return Visitor::apply(s, e);
}
template<class EventType>
static State applyHelper(State s, EventType e, long) // long gives a lower precedence
// in overload resolution when argument is 0
{
return s;
}
Then the implementation of Applicator::apply can be
static State apply(State s, Event e) {
return std::visit([&](auto e) { return applyHelper(s, e, 0); }, e);
}
answered Jan 4 at 10:46
cpplearnercpplearner
4,99021936
add a comment |
If the Visitor can always apply, then the code can be as simple as
return std::visit([&](auto e) { return Visitor::apply(s, e); }, e);
But since Visitor cannot always apply, we need to use SFINAE, which requires a set of overloaded function templates. The function templates can be defined like this:
template<class EventType>
static auto applyHelper(State s, EventType e, int)
-> decltype(Visitor::apply(s, e)) // only enabled if Visitor::apply(s, e) is a valid expression
{
return Visitor::apply(s, e);
}
template<class EventType>
static State applyHelper(State s, EventType e, long) // long gives a lower precedence
// in overload resolution when argument is 0
{
return s;
}
Then the implementation of Applicator::apply can be
static State apply(State s, Event e) {
return std::visit([&](auto e) { return applyHelper(s, e, 0); }, e);
}
answered Jan 4 at 10:46
cpplearnercpplearner
4,99021936
add a comment |
If the Visitor can always apply, then the code can be as simple as
return std::visit([&](auto e) { return Visitor::apply(s, e); }, e);
But since Visitor cannot always apply, we need to use SFINAE, which requires a set of overloaded function templates. The function templates can be defined like this:
template<class EventType>
static auto applyHelper(State s, EventType e, int)
-> decltype(Visitor::apply(s, e)) // only enabled if Visitor::apply(s, e) is a valid expression
{
return Visitor::apply(s, e);
}
template<class EventType>
static State applyHelper(State s, EventType e, long) // long gives a lower precedence
// in overload resolution when argument is 0
{
return s;
}
Then the implementation of Applicator::apply can be
static State apply(State s, Event e) {
return std::visit([&](auto e) { return applyHelper(s, e, 0); }, e);
}
answered Jan 4 at 10:46
cpplearnercpplearner
4,99021936
If the Visitor can always apply, then the code can be as simple as
return std::visit([&](auto e) { return Visitor::apply(s, e); }, e);
But since Visitor cannot always apply, we need to use SFINAE, which requires a set of overloaded function templates. The function templates can be defined like this:
template<class EventType>
static auto applyHelper(State s, EventType e, int)
-> decltype(Visitor::apply(s, e)) // only enabled if Visitor::apply(s, e) is a valid expression
{
return Visitor::apply(s, e);
}
template<class EventType>
static State applyHelper(State s, EventType e, long) // long gives a lower precedence
// in overload resolution when argument is 0
{
return s;
}
Then the implementation of Applicator::apply can be
static State apply(State s, Event e) {
return std::visit([&](auto e) { return applyHelper(s, e, 0); }, e);
}
answered Jan 4 at 10:46
cpplearnercpplearner
4,99021936
answered Jan 4 at 10:46
cpplearnercpplearner
4,99021936
answered Jan 4 at 10:46
cpplearnercpplearner
4,99021936
answered Jan 4 at 10:46
cpplearnercpplearner
4,99021936
4,99021936
add a comment |
add a comment |
Well, std::is_invocable_r looks like the tool of choice.
Unfortunately, you would have to get the type of the right overload, which would completely defeat the purpose.
Instead, go one step back and use std::is_detected from library fundamentals TS v2 or equivalent and a template:
template <class... Xs>
using can_Visitor_apply = decltype(Visitor::apply(std::declval<Xs>()...));
if constexpr(std::is_detected_convertible<State, can_Visitor_apply, State&, Event&>())
return Visitor::apply(s, e);
The advantage is that you have a compile-time-constant to hang arbitrary decisions on. The disadvantage is not (yet) having a function which you can simply just call and forget about it.
answered Jan 4 at 10:44
DeduplicatorDeduplicator
34.3k64888
add a comment |
Well, std::is_invocable_r looks like the tool of choice.
Unfortunately, you would have to get the type of the right overload, which would completely defeat the purpose.
Instead, go one step back and use std::is_detected from library fundamentals TS v2 or equivalent and a template:
template <class... Xs>
using can_Visitor_apply = decltype(Visitor::apply(std::declval<Xs>()...));
if constexpr(std::is_detected_convertible<State, can_Visitor_apply, State&, Event&>())
return Visitor::apply(s, e);
The advantage is that you have a compile-time-constant to hang arbitrary decisions on. The disadvantage is not (yet) having a function which you can simply just call and forget about it.
answered Jan 4 at 10:44
DeduplicatorDeduplicator
34.3k64888
add a comment |
Well, std::is_invocable_r looks like the tool of choice.
Unfortunately, you would have to get the type of the right overload, which would completely defeat the purpose.
Instead, go one step back and use std::is_detected from library fundamentals TS v2 or equivalent and a template:
template <class... Xs>
using can_Visitor_apply = decltype(Visitor::apply(std::declval<Xs>()...));
if constexpr(std::is_detected_convertible<State, can_Visitor_apply, State&, Event&>())
return Visitor::apply(s, e);
The advantage is that you have a compile-time-constant to hang arbitrary decisions on. The disadvantage is not (yet) having a function which you can simply just call and forget about it.
answered Jan 4 at 10:44
DeduplicatorDeduplicator
34.3k64888
Well, std::is_invocable_r looks like the tool of choice.
Unfortunately, you would have to get the type of the right overload, which would completely defeat the purpose.
Instead, go one step back and use std::is_detected from library fundamentals TS v2 or equivalent and a template:
template <class... Xs>
using can_Visitor_apply = decltype(Visitor::apply(std::declval<Xs>()...));
if constexpr(std::is_detected_convertible<State, can_Visitor_apply, State&, Event&>())
return Visitor::apply(s, e);
The advantage is that you have a compile-time-constant to hang arbitrary decisions on. The disadvantage is not (yet) having a function which you can simply just call and forget about it.
answered Jan 4 at 10:44
DeduplicatorDeduplicator
34.3k64888
edited Jan 4 at 10:50
answered Jan 4 at 10:44
DeduplicatorDeduplicator
34.3k64888
answered Jan 4 at 10:44
DeduplicatorDeduplicator
34.3k64888
answered Jan 4 at 10:44
DeduplicatorDeduplicator
34.3k64888
34.3k64888
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54036439%2fnamed-static-dispatching-with-stdvariant%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Aside: is
Statereally meant to be a member ofVisitor?– Caleth
Jan 4 at 11:12
@Caleth yes, the Visitor is just used as a namespace to handle different kinds of events so it should encapsulate both the state and the operations that operates on that state. This is a very contrived example though.
– aerkenemesis
Jan 4 at 11:28
1
then it should be
typename Visitor::StateinApplicator(orVisitor::Stateif you drop the template parameter that shadows the class)– Caleth
Jan 4 at 11:31
Well I didn't try compiling it since it contains pseudo code, as I said - it is a contrived example.
– aerkenemesis
Jan 4 at 12:47