title: Visitor pattern and constness
body: <p>I am running into a problem concerning the visitor pattern and constness.</p>
  
  <p>Assume a visitor pattern implementation in C++ for a small game in which you draw stuff on the screen (depending on the internal state of the drawable objects) and at the same time run a logic that can change their internal state (pretty much any game you can imagine). Please, forgive any errors in code as this is done on the fly. </p>
  
  <pre><code>//Forward declaration of classes and visitor...
  
  //class Game_actor; This one will be abstract, virtual, whatever.
  class Game_actor_item;
  class Game_actor_player;
  class Game_actor_invisible;
  
  class Visitor
  {
      public:
  //  virtual void visit(Game_actor&amp; r)=0;
      virtual void visit(Game_actor_player&amp; r)=0;
      virtual void visit(Game_actor_item&amp; r)=0;
      virtual void visit(Game_actor_invisible&amp; r)=0;
  };
  </code></pre>
  
  <p>Then, some interface-like basics:</p>
  
  <pre><code>//This one defines stuff that can be on the screen.
  
  class Drawable
  {
      public:
      virtual void draw(Screen&amp;)=0;
  };
  
  //This one defines stuff that changes its state. Let's assume that do_logic 
  //returns an integer that means something to the controller and can be 
  //interpreted via a long list of "message_codes" (1=Add score, 2=Substract 
  //score, 3=Something else...). Each actor will run its logic and return its 
  //message, that will be stored and interpreted later. This is mostly crap, 
  //I know, but makes for a quick example.
  
  class Game_actor
  {
      private:
  
      float x;
      float y;
  
      public:
      virtual int do_logic()=0;
      void accept_visitor(Visitor&amp; v)=0;
  };
  </code></pre>
  
  <p>Next, our object hierarchy: Items and the player are derived from the actor, that defines part of their internal state. They can, of course, be drawn to the screen. There's a particular actor that won't be drawn, because it is invisible and controls something else.</p>
  
  <pre><code>class Game_actor_item: public Drawable, public Game_actor
  {
      //Lines and lines of code.
      virtual void draw(Screen&amp; s) {/* [...] */}
      virtual int do_logic() {/* [...] */}
  };
  
  class Game_actor_player: public Drawable, public Game_actor
  {
      //Lines and lines of code.
      virtual void draw(Screen&amp; s) {/* [...] */}
      virtual int do_logic() {/* [...] */}
  };
  
  class Game_actor_invisible: public Game_actor
  {
      //Lines and lines of code.
      virtual int do_logic() {/* [...] */}
  };
  </code></pre>
  
  <p>Finally, visitor specialization. We're gonna define two visitors, one is going to collect all drawable actors and other is going to dispatch messages to the game controller. Drawable actors will be collected from
  a vector of its base class </p>
  
  <pre><code>class Visitor_drawing:public Visitor
  {
      private:
      std::vector&lt;Drawable *&gt; draw_all_these;
  
      public:
  //  virtual void visit(Game_actor&amp; r) 
      virtual void visit(Game_actor_player&amp; r) {draw_all_these.push_back(&amp;r);}
      virtual void visit(Game_actor_item&amp; r) {draw_all_these.push_back(&amp;r);}
  
      //This one won't be drawn.
      virtual void visit(Game_actor_invisible&amp;) {}
  
      std::vector&lt;Drawable *&gt; get_me_the_drawables() {return draw_all_these;}
  }
  
  class Visitor_logic:public Visitor
  {
      private:
      std::vector&lt;int&gt; messages;
  
      public:
  //  virtual void visit(Game_actor&amp; r) 
      virtual void visit(Game_actor_player&amp; r) {messages.push_back(r.do_logic());}
      virtual void visit(Game_actor_item&amp; r) {messages.push_back(r.do_logic());}
      virtual void visit(Game_actor_invisible&amp;) {messages.push_back(r.do_logic());}
  
      std::vector&lt;int&gt; fetch_me_the_messages() {return messages;}
  }
  </code></pre>
  
  <p>So, that's our setup. It is missing the "accept_visitor" methods, but I'm sure you get the idea here. Every final branch of the hierarchy just does void accept_visitor(Visitor&amp; v) {v.visit(*this);}. </p>
  
  <p>At any given time in our loop we collect drawable things and run logic:</p>
  
  <pre><code>std::vector&lt;Game_actor*&gt; actors;
  
  while(loop)
  {
      Visitor_drawing dw;
      Visitor_logic dl;
      for(Game_actor * g : actors)
      {
          dw.visit(g);
          dl.visit(g);
      }       
  
      std::vector&lt;Drawable *&gt; draw_these=dw.get_me_the_drawables();
      std::vector&lt;int&gt; messages=dl.fetch_me_the_messages();
  
      for(Drawable * d : draw_these) d-&gt;draw(screen);
      for(int * m : messages) interpret_message(m);
  };
  </code></pre>
  
  <p>And here's my problem: I really want to keep my objects const where they should be. One requisite for this is that drawing them is never going to change their internal state (save a mutable int times_drawn, for example) so they could (and should (??)) be const. Doing their logic may change their state at each given turn (for example, moving them around the screen).</p>
  
  <p>Given this particular setup, how would you manage having a const and non const visitor?. I have tried splitting the base visitor into const and non const base classes so they do</p>
  
  <pre><code>class Const_visitor
  {
      virtual void visit(const Thing&amp;)=0;
  };
  
  class Non_const_visitor
  {
      virtual void visit(Thing&amp;)=0;
  };
  
  class Visitor_drawing:public Const_visitor
  {
      virtual void visit(const Thing&amp;)=0;
  };
  
  class Visitor_logic:public Non_const_visitor
  {
      virtual void visit(Thing&amp;)=0;
  };
  </code></pre>
  
  <p>But it seems that I would have to implement separate "accept_visitor" methods as the compiler doesn't distinguish between calls:</p>
  
  <pre><code>void accept_visitor_const(Const_visitor&amp; v)=0;
  void accept_visitor(Non_const_visitor&amp; v)=0;
  </code></pre>
  
  <p>This leads to all kinds of duplication in the base visitor classes (basically writing everything twice, const and non const versions) and then separating the calls in the main loop: there's no single accept_visitor anymore and you have to know in advance what kind of visitor are you expecting (the side effect is that it really reads "I will accept this visitor that promises not to change my internals", which is somewhat desirable).</p>
  
  <p>Anyway, Am I missing any other option that does not radically change this setup?. Is this a suitable and desirable option?</p>
  
  <p>As always, many thanks in advance.</p>