   const class member
  Can someone clarify this topic..Lets say I have a map class which holds my hexagonsclass Map{private:Hexagon map[42][25];public:Hexagon *getHex(int x,int y){return map[x][y];};};Then I have a army class and I want each army have a pointer that points to the hexagon its currently on.class Army{private:Hexagon *m_pHex;public:void setHex(const Hexagon *pHexagon){m_pHex = pHexagon;};};Well this doesnt work.It says cant convert from const Hexagon* to Hexagon.What would be the best way to do this?Should I make the m_pHex const???or remove the const from the setHex function?What about *getHex should it be const Hexagon *getHex()??All this const stuff is confusing me...   
  tryHexagon *getHex(int x,int y){return &map[x][y];};   ;  It is complaining because the pointer that you pass into the function is pointing to a constant data type, and you are trying to assign it to a pointer that points to a non-constant data type.  Obviously, if you take a pointer to a constant and then assign it to a pointer to a non constant, you are now able to modify data that is supposed to be constant.Basically, you need to make the Hexagon pointer in your Army class a pointer to a constant data source, or set the function parameter so that the pointer doesn't point to constant data (Hexagon *).  You can also use a const_cast to remove the const-ness.Note you should still be able to assign to the pointer if you make it const Hexagon *.  That declares a non-constant pointer that points to a const Hexagon.   ;  To fix your error, you would do it like this:class Army    {    private:   const Hexagon *m_pHex;    public:   void setHex(const Hexagon *pHexagon){m_pHex = pHexagon;};    }; However, that might be inconvenient, because you might want to change the hexagon through the army's pointer and you can't because it is const. In that case, you might do this:class Army    {    private:   Hexagon *m_pHex;    public:   void setHex(Hexagon *pHexagon){m_pHex = pHexagon;} // Removed const    }; But the real solution is to not give the army a pointer, but to give it a "key" instead. The reason is that (in general) you don't want other code holding pointers to a class's internal and private data. You would do something like this:class Map    {    private:   Hexagon map[42][25];    public:   typedef ... Hex_ref;   ...   Hexagon & getHex( Hex_ref hex ) { return ... }   Hexagon const & getHex( Hex_ref hex ) const { return ... }    };    class Army    {    private:   Map::Hex_ref m_Hex;    public:   void setHex(Map::Hex_ref hex){m_Hex = hex;}    }; The benefit is that Map doesn't have to worry about other classes holding stale pointers. However, its adds additional complication and so you have to decide which way is better for you in the long run.   ;  Even if you don't want to "key" things, you should still use references rather than pointers (to simplify the calling code) and do the illustrated "const overloading" (to allow you to work with const Maps, and other such things, while satisfying the compiler):class Map {  Hexagon map[42][25];  public:  Hexagon & getHex(int x, int y) { return map[x][y]; } // no pointer manipulation here  Hexagon const & getHex(int x, int y) const { return map[x][y]; } // or here};    class Army {  Hexagon* m_Hex; // Slight deviance here: storing pointers is easier to get  // right than storing references IMX... fortunately it's not difficult to  // convert properly, as shown.  public:  // The Army should probably do the work of "asking the map" itself:  void setHex(Map m, int x, int y){ m_Hex = &(m.getHex(x, y));}};// Other calling code that wants to work with a map still doesn't have to deal// with pointers:Map myMap;myMap.getHex(0,0).animate(); // this animates the hex that is already in that// map; it does *not* create a copy and animate the copy, the way that would// happen if you returned a value rather than a reference. But you still get to// write code *as if* it were a value, so you don't have to muck around with// pointers. Oh, and it gives the compiler more information, as well as giving// yourself more information. Compilers like having more information. Sometimes// it lets them do cooler optimizations. :);  Ok thans for all the usefull information guys :)   ;  Here's something I found very useful myself:http://www.parashift.com/c++-faq-lite/const-correctness.html   