One point of the visitor pattern is to avoid the need of the repetition of code like this

process(Shape s) {
    if(s instanceof Circle) {
        visitCircle(s);
    }
    if(s instanceof Dot) {
        visitDot(s);
    }
    if(s instanceof CompoundShape)
    {
         // some code to process all inner shapes of s
    }
...
...
else {
  // fail with an exception
}

in each concrete visitor. Your solution fails this point, since the code above will be repeated inside XMLShapeProcessor, MarkdownShapeProcessor, FooShapeProcessor, BarShapeProcessor etc. over and over again.

There are surely cases where this kind of repetition is acceptable. When your object hierarchy provides some generic iterator mechanism to retrieve all objects from a graph (including all child objects), and the visitors themselve don’t care for a very specific order in which the graph is traversed, and in case there are only a few concrete classes in the traversed graph, then the code section above will stay quite simple and not too large, hence chances are not too bad the repetition will not cause a huge maintenance headache.

However, it is quite easy to implement this generically, in a DRY fashion, still without an accept method. Just place process somwhere else (maybe in a Dispatcher class or a stand-alone function in C++), and make the visitor a parameter of that function:

process(Shape s, Visitor v) {
    if(s instanceof Circle) {
        v.visitCircle(s);
    }
    if(s instanceof Dot) {
        v.visitDot(s);
    }
    ...
    ...
    else ...

That should do the trick. As Pete Kirkham correctly wrote, the C++ used in the GoF book was avoiding things like RTTI or direct type checks which were not standardized in 1995, hence this kind of solution was probably not on the agenda of the authors.

Final remark: you wrote your approach makes use of the Strategy pattern, pretending this would be the core difference to the original GoF Visitor. But in the original GoF Visitor, classes like XMLExportVisitor, MarkdownExportVisitor can be already be interpreted as different export strategies, just like an XMLExportProcessor or an MarkdownExportProcessor. So I don’t think this is a useful distinction.

The Visitor pattern as presented in ‘Design Patterns: Elements of Reusable Object-Oriented Software’ is one of the patterns which are there to overcome a limitation in the implementation language.

The GoF book was published in 1994 before RTTI was added to C++ *, so there was no equivalent of instanceof available to use for the visitor pattern, or better multiple dispatch mechanisms as are available in Lisps or more modern languages **.

So, yes, now you can use run time type information in languages that have it to do multiple dispatch, and you might lose some static type checking and performance by doing that, depending on language. Whether it is better or not rather depends on the language rather than something general, since the pattern is only there in that form for languages which don’t have something better already. You would not use the pattern in Lisp as you already have multi-dispatch methods.

* or at least it was written before it was commonly implemented in compilers, I’m not 100% sure of the timeline

** more modern than 1994 in case people again start pointing out that Python isn’t that modern.

Are there downsides with the approach I’m trying to implement that the Visitor pattern doesn’t have?

1. It values visiting hierarchies which are not designed up-front to be visitable, which was never a particular goal of the visitor pattern
2. It values simplifying the visitee over complicating the visitor
3. (equivalently) it values ease of adding visitee types over ease of adding new visitor types
4. It can fail (or silently misbehave) if the visited hierarchy has non-final intermediate types which may be used for real objects. At least, it’s brittle because you need to carefully test the types in the correct order (reverse topological sort), and this needs to be manually maintained in every visitor

All of these may be valid choices for a particular scenario, but IMO you’re exaggerating how widely applicable they are.

• Didn’t contaminate my Shape interface with an accept() method.
• Didn’t contaminate my concrete shapes with knowledge about a visitor.

…

• I can apply this pattern to 3rd party code.

These all say the same thing: that you want to detach the mechanism for visiting some hierarchy, from the hierarchy itself.

Fortunately there are other ways to do this that don’t require writing a sequence of instanceof tests by hand, in every visitor.

Taking a step back, the general problem we’re addressing is called “double dispatch”. Single dispatch is where the concrete method actually called depends on the (single) dynamic type of the object it’s called on. Double dispatch is where the concrete method actually called depends on two types (here, the visitee and the visitor).

A better solution than your original would be a standalone double-dispatcher: it has the same brittleness I described above (point 4), but at least only has to be written once.

One is version is the straight translation already posted by Doc Brown:

  visit(Shape s, ShapeVisitor v) {
    if(s instance of Circle) {
      v.visitCircle(asCircle(s));
    }
    if(s instance of Dot) {
      v.visitDot(asDot(s));
    }
    ...
    ...
    else {
      // fail with an exception, return null... whatever you want.
    }
  }

Another, depending on language, is the more data-driven style:

class DD {
map<pair<typeid,typeid>, method> map_;

public:
  dispatch(auto& visitee, auto& visitor)
  {
    pair key{typeof(visitor),
             typeof(visitee)};
    map_[key](visitee, visitor);
    // with handling for missing keys
  }
};

This is more work to set up, but can work as glue layer when neither hierarchy was designed for visitation.

There are differences between using the classic Visitor implementation (with an accept method), and your suggested implementation (where the dispatch is made by instanceof, without accept).

With the classic implementation it is possible to work with private fields…

accept(Visitor v) {
    
    shapeImplementation = new ....
    shapeImplementation.property = this.privateProperty;
    
    v.visit(shapeImplementation);
}

…since by passing the visitor to the visited object the visited object could expose to the visitor what it consider being of interest.

The implementation with instanceof, outside the visited objects, can work just with accessible fields/properties.

In other words, with the classic Visitor implementation, what’s private can stays private. An implementation without an accept method, what was formerly private needs to be exposed to join to the implemented end to end behaviour.

I talked about differences, to talk about down sides the context should be described in more details.

In a different terminology than the design patterns one, the Visitor model from the description fails or could be improved by following SOLID principles, specifically open closed principle.

For reference, a quick definition of each principle:

Single-responsibility principle: “There should never be more than one reason for a class to change.” In other words, every class should have only one responsibility.

Open–closed principle: “Software entities should be open for extension, but closed for modification.”

Liskov substitution principle: “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”

Interface segregation principle: “Clients should not be forced to depend upon interfaces that they do not use.”

Dependency inversion principle: “Depend upon abstractions, [not] concretes.

That is design the Visitor agnostic to adding new types unless Dot, Circle, Rectangle, CompoundShape are the all possible Shape implementations and then there aren’t down sides.

I’ve never liked the Visitor pattern, and I think it rightfully gets a lot of hate. It creates a tangled mess of coupling. Every new shape requires a new implementation in both your vistor interface and every concreate visitor class.

In addition, what’s odd to me about the example that you link to is that the GoF Builder pattern (not to be confused with Josh Bloch’s pattern of the same name) seems more appropriate for the problem at hand. I find it to be a ‘saner’ approach in general, and it can be adapted fairly easily. It avoids the bi-directional coupling inherent in visitor.

That said, discussing patterns with such abstract examples isn’t very useful, in my experience. The details of a specific problem to be solved are necessary to truly judge a design approach (patterns or otherwise) for appropriateness.

The major downside of the approach you describe is that you retain the main disadvantages of the visitor: every new class of object you want to handle requires a new ‘implementation’ in your processor method. I used to be strongly in the camp that using the type of objects like this was a problem in itself. I’ve softened on that but it’s not something I would use over a large set of types, and/or if the set of types is expected to grow over time.