Live data from Hacker News

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

cppcrypt.tumblr.com

51–60 of 64 posts

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

#51
post #17

Earlier quoted context omitted.

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.

If you build your visitor out of lambdas, instead of a struct, you can propagate local state to the visitor easily by using lambda captures. There are good examples of this approach at https://en.cppreference.com/w/cpp/utility/variant/visit

Unfortunately, you can't leverage template substitution rules with the lambda approach. And that's really necessary if you want to have actual powerful match expressions.

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

#52

The only time I have ever encountered a code base where the visitor pattern was necessary and fulfilling its purpose is Babel (the JS compiler).

Agreed. The _only_ times I've ever been justified in implementing this pattern have been when doing compiler work. Someone else up-thread mentioned what I think is the key requirement making visitors worthwhile is non-trivial tree traversal. ASTs seem to fit this description more than any other data structure I've had to work with day-to-day. Outside of language trees, I wonder where else visitors are common?

ETL for very complex data structures maybe? Oh the irony. I've never seen the visitor pattern used in an ETL pipeline, which might be why they're always such God forsaken messes.

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

#53

The visitor pattern isn't appropriate everywhere, but it's quite good for traversing and manipulating ASTs (abstract syntax trees). An AST typically has many kinds of nodes, but programs that traverse the AST usually only care about some small subset of those nodes. The visitor pattern provides a clean solution: a generic AST traversal library visits all nodes in the tree while allowing the program to customize what…

But often a pattern matching switch expression would be nicer, if your language has such a thing.

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

#54
post #46

What a terrible UI on that website. Constantly clicking "Next"! Yuk. And every page required zooming in and out to make it fit on my screen. For a tech focused comic, you'd think the author could run it through an ImageMagick batch resize job. Bonus points for allowing keyboard back and forth navigation.

You can click anywhere on the image too; not aiming for that tiny [next] does help a bit.

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

#55
post #32

Earlier quoted context omitted.

It's a shortcoming of languages that don't have multiple dispatch.

Why should anyone force changes into the core language if all you want to do is use an obscure programming construct in a corner case that's easily implemented with a design pattern? Some of these complains are at best very misguided.

The short answer is that the existence of multiple dispatch isn't motivated by the visitor pattern.

Moreover, multiple dispatch isn't obscure at all.

C++ has it, but only statically, for instance, in the form of overloaded functions. C++ chooses a function overload by looking at the types of all parameters and arguments.

Multiple dispatch is similar, but the run-time types of the arguments are used.

This is broadly applicable in making all sorts of situations nicer.

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

#56
post #46

What a terrible UI on that website. Constantly clicking "Next"! Yuk. And every page required zooming in and out to make it fit on my screen. For a tech focused comic, you'd think the author could run it through an ImageMagick batch resize job. Bonus points for allowing keyboard back and forth navigation.

I agree, horrible, luckily I use vimium so after the first page it was a repetitive key sequence to move forward

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

#57
post #10

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

Until C++2z rolls out with match support, you can roll your own. Nikolai Wuttke gave a lecture at MeetingCpp 2018 ( https://www.youtube.com/watch?v=CELWr9roNno ) that presents code that lets you do this: // Client visitor code match( thingy, [](const PurpleThingy& ) {std::cout Working example: https://coliru.stacked-crooked.com/a/dfed39bc7fcdfb01

[deleted]

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

#58

Earlier quoted context omitted.

Why should anyone force changes into the core language if all you want to do is use an obscure programming construct in a corner case that's easily implemented with a design pattern? Some of these complains are at best very misguided.

Why have functions and control structures when we can just jmp?

That's a disingenuous comparison. Functions are used pervasively, but even the visitor pattern isn't used very often.

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

#59
post #32

Earlier quoted context omitted.

It's a shortcoming of languages that don't have multiple dispatch.

Why should anyone force changes into the core language if all you want to do is use an obscure programming construct in a corner case that's easily implemented with a design pattern? Some of these complains are at best very misguided.

Have you considered that multiple dispatch is obscure because it requires jumping through such hoops to implement in most mainstream languages, rather than because of its lack of utility?

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

#60
The thing with the visitor pattern is that it indeed is useful for many operations over fixed data. But the same holds for simple pattern matching. Inheritance (or rather subtyping) is useful for changing data but a fixed set of operations. But what the eff do we do when we have many operations on changing data? The expression problem still is an interesting problem, because a data structure that solves it would basically be the "gold standard".
Post reply on HN