title: Is the Visitor Pattern the fastest way to differentiate parameter types in C++?
body: <p>Is the Visitor Pattern the fastest way to accomplish method parameter type identification (effectively single dispatch on a parameter, not a member's class) in C++?  I might know the exact method(s) I want to invoke on elements of not-yet-know subtype, so invariably making an additional virtual method call like <code>V::visit(A *)</code> in <code>A::accept(V &amp;v) { v.visit(this); }</code> is undesirable.</p>
  
  <pre><code>// Is the Visitor pattern recommended here?  (E inherits D inherits B.)
  class Foo {
  public:
    virtual void visit(B *) { result = 3; }
    virtual void visit(D *) { result = 4; }
    virtual void visit(E *) { result = 5; }
  private:
    int result;
  }; // class Foo
  
  // Need to add generic interface to B and its children ...
  class B {
  public:
    virtual void accept(class Foo &amp;f) { f.visit(this); }
  }; // class B
  </code></pre>
  
  <p>I'd like something functionally equivalent the following but with O(1) cost, which is AFAIK not possible with dynamic_cast&lt;> or typeid() ladders, since <code>std::type_info</code> can't be a constexpr/switchable.</p>
  
  <pre><code>// O(n) search cost might get nasty with bigger hierarchies.
  int foo(B *b) {
    if (typeid(b) == typeid(B *)) { return 1; }
    if (typeid(b) == typeid(D *)) { return 2; }
    if (typeid(b) == typeid(E *)) { return 3; }
    return -1;
  }
  </code></pre>
  
  <p>What are my options here?  Thanks for the advice!</p>
  
  <p><strong>Edit:</strong> Changed sample code to feed results through field, such that multiple signatures aren't needed for different method types.  Thanks, Maurice!</p>
  
  <p><strong>Final decision:</strong> In addition to not liking the mandatory double dispatch cost of the Visitor Pattern, I also wanted to avoid the interface bloat of overloading <code>foo()</code>, but I don't think that there is a known clean pattern to do this.  I ended up just doing straight static overloads and called it a day.  Anyway, my wanting to encapsulate overloading inside a function is probably a questionable goal at best.  Thanks, Maurice for the response.</p>