Grim C++ Tales from the Crypt: The Visitor Pattern (2017) • Hacker News Board

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#11

Post by codetrotter » Wed, Mar 06, 2019, 3:03 PM UTC

Alterlife wrote: post #4

If you're like me and couldn't get past the first few slides because it's a terrible reading experience, go to the archive, which shows the whole thing in thumbnails. It makes it little better, even though the thumbnails are in reverse: https://cppcrypt.tumblr.com/archive

I requested desktop site and then from there I read them one by one, tapping the “next” links. It was very readable IMO but I am used to having read cartoons online before that you navigate like this so.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#12

Post by rgoulter » Wed, Mar 06, 2019, 3:04 PM UTC

The example code the author comes up with: https://github.com/dpugson/examples/blob/master/chpt1_the_vi...

Which implements the pseudocode: https://cppcrypt.tumblr.com/post/168134402897

    main {
        thingies = [ purpleThingy, littleThingy ]
        interactions = [ commentOn, cherish ]

        for (interaction in interactions)
          for (thing in thingies)
             interaction.interact(thing)
    }

The author does mention things like "function pointers can be used in simple cases" and "std::variant would avoid the need to overload the method". But the main reason for having the C++ code the way it is is because "you can't dispatch to overloaded methods at runtime". https://cppcrypt.tumblr.com/post/169439207562 ff.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#13

Post by deckar01 » Wed, Mar 06, 2019, 3:07 PM UTC

I don't understand why the class instance needs to accept the interaction. Why not just invoke the interaction directly?

    interactor_p->interact(thingy_p)

Would this still be considered the visitor pattern or is the extra layer of indirection important?

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#14

Post by fraffo » Wed, Mar 06, 2019, 3:12 PM UTC

deckar01 wrote: post #13

I don't understand why the class instance needs to accept the interaction. Why not just invoke the interaction directly? interactor_p->interact(thingy_p) Would this still be considered the visitor pattern or is the extra layer of indirection important?

Your code won't compile because interactor::interact is not defined on the base class. That line is needed because the overload resolution is static. So with the macro ACCEPTS, you build the code where the overload is resolved.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#15

Post by deckar01 » Wed, Mar 06, 2019, 3:21 PM UTC

fraffo wrote: post #14

deckar01 wrote: post #13

I don't understand why the class instance needs to accept the interaction. Why not just invoke the interaction directly? interactor_p->interact(thingy_p) Would this still be considered the visitor pattern or is the extra layer of indirection important?

Your code won't compile because interactor::interact is not defined on the base class. That line is needed because the overload resolution is static. So with the macro ACCEPTS, you build the code where the overload is resolved.

I see. There is no interact signature that accepts IThingy, which is the whole point of this pattern. Thanks.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#16

Post by mcv » Wed, Mar 06, 2019, 3:29 PM UTC

This... I can actually see the point in this. The Visitor pattern is one of those patterns I never really saw the point of, and which mostly struck me as an over-engineered hack about a shortcoming in a language.

This example actually makes clear why you'd need to do it this was in C++ at least. Not sure which other languages would need this. It's certainly not pretty. Then again, dispatching twice is not so bad compared to your average Java-style over-engineering.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#17

Post by Chabs » Wed, Mar 06, 2019, 3:43 PM UTC

adgasf wrote: post #10

C++ match expressions would make std::variant a really nice alternative. I assume there is already a proposal out?

std::visit mostly allows you to do that already:

https://coliru.stacked-crooked.com/a/be5c44281eea8bc4

Then only unfortunate missing piece of the puzzle is that there's no trivial way to create a closure out of this, so it requires a bit more manual work to propagate local state to the visitor.

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#18

Post by monk_the_dog » Wed, Mar 06, 2019, 3:45 PM UTC

adgasf wrote: post #10

C++ match expressions would make std::variant a really nice alternative. I assume there is already a proposal out?

Pattern matching is on many people's radar, including the "Direction Group" (See: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p093...). This proposal was discussed at the committee meeting last month: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p137... I'd love to see it standardized in 23, but I have no idea how likely that is. (It definately won't be in c++-20, which is now closed except for tweaks).

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#19

Post by exitb » Wed, Mar 06, 2019, 3:56 PM UTC

adgasf wrote: post #10

C++ match expressions would make std::variant a really nice alternative. I assume there is already a proposal out?

For reference, Rust version shows how much simpler that could be with pattern matching - https://gist.github.com/km216/aad5c0fa11f32aa562af2370a32208...

Re: Grim C++ Tales from the Crypt: The Visitor Pattern (2017)

#20

Post by patientplatypus » Wed, Mar 06, 2019, 3:58 PM UTC

So annoying. I had to click through 20 slides of a cartoon dog acting weaboo to see the code example and I still don't see why the pattern is bad - which was the initial implication of the post. Why do people bury their thesis in horrible garbage like this? Sometimes I wish people were normal.