title: Chess piece hierarchy design: inheritance vs type fields
body: <p>I have a base class for pieces</p>
  <pre><code> class piece;
  </code></pre>
  <p>and an array containing derived objects</p>
  <pre><code>piece* board[8][8];
  </code></pre>
  <p>Advantage, clean design through virtual functions. Disadvantage, if I have to find a piece in the board or compare a piece I have to revert to dynamic casting (or typeid). It’s ugly and could be a performance hog when making millions of requests.</p>
  <p>In the other hand, if I make an array of a single piece class, that has a type field for identifying pieces, I don’t have this problem (and it should be faster) but I have to make super ugly switch statements. I guess that since the number of pieces is finite and I don’t see myself making that many of switches, this could be in the end a better choice, what do you think?</p>
  <p>This is for fun (so no bitboard).</p>
  <p>Reading some answers, I think using type fields only for operator overloading (<code>==</code>, <code>!=</code>, ...) could bring the best of both words.</p>
  <p>The <code>boost::variant</code> looks very interesting too.</p>