class Tile {  // Members of a class default to private, thus my convention is to put private  // stuff first.  static std::map<std::string, std::pair<BITMAP, int> > images;  // Several things to notice here. The map is a templated type, as is the  // "pair"; read it as "map OF string TO (pair OF BITMAP AND int)".  // std::pair is just a quick way of making a struct with two data members,  // basically. Here the BITMAP is the bitmap, and the int is a "reference  // count" - the number of constructed Tile objects using this bitmap.  // Finally, the "static" means that there is one *shared* instance of the map  // for the whole class, rather than one per Tile object - this is how it  // should be.  // This design has the Tile class managing the Tile objects. I find this sort  // of design to be clean and compact; however, there are good arguments for  // factoring out the management to a separate class, too. (I just don't happen  // to agree with those arguments most of the time. ;) )  std::string myImage; // a "key" for the map.  int row, column; // position in the indicated bitmap for drawing.  // I will also need a private helper function, that will become clear later...  void dispose() {    // Decrements the reference count for the current object's BITMAP, to say    // "I am not using this bitmap any more."    std::pair<BITMAP, int>& theBitmap = images[myImage];    --theBitmap.second;    if (!theBitmap.second) { // that was the last user, so we must      // unload the image now.      cleanupBitmap(theBitmap.first);      // Warning! Don't try to invoke ~BITMAP directly yourself; it's bad mojo.      // What you probably want to do is just something like "theBitmap.first =      // BITMAP();", i.e. assign a blank BITMAP to it, and let the BITMAP       // assignment operator take care of things for you.      // And now, remove the item from the map.      images.erase(myImage);    }  }  public:  // And now, the public functions.  Tile(std::string imageName, int r, int c) : myImage(imageName), row(r), column(c) {    // Notice how I used an initializer list (google them - possibly with    // "site:gamedev.net" - if that's not familiar to you) to set up the data    // members, since they can just be copied across.    // Now, we do the magic part of possibly loading a bitmap.    // The operator[] on a map is a lookup-with-side-effect; it will return    // a default-constructed "value" (here, a pair of int and BITMAP, i.e. the    // the int will be 0 and the BITMAP will be whatever it is) if the "key" is    // not found, and otherwise returns the matching "value". In our case, if    // the key is not found, we want to insert anyway, so this is OK. (Note that    // the value is returned by non-const reference, so we can then modify the    // value in the map directly.) Note how I store to a reference, rather than    // a value, in order to preserve that modifiability over a few lines of code    // :)    std::pair<BITMAP, int>& theBitmap = images[myImage];    if (!theBitmap.second) { // the int is 0; i.e. we need to load      theBitmap.first = createBitmap(myImage);      // the createBitmap function should open the named file, do the actual      // creation, close the file (that can happen implicitly, e.g. if you use      // an ifstream object, it will close automatically at the end of scope)      // and return the BITMAP.    }    ++theBitmap.second; // In any case, there is now one more Tile using    // that image than there was before.  }  void drawSelf(int x, int y) {    // Method to draw the tile. Note we are guaranteed that the bitmap is loaded    // and its name is in the map, because that was handled in the constructor.    // So again we can just use the operator[]:    BITMAP b = images[myImage];    drawImageChunk(x, y, b, row, column); // Again, this is yours to implement  }  ~Tile() {    // The destructor. When we destruct a tile, we have to decrease that    // reference count for its image (since there's now one fewer tile kicking    // around that uses it), and unload the image if appropriate.    dispose();    // Because all the per-object data consisted of primitives (int values) and    // a std::string (which knows how to clean itself up), there is no more to    // do here. Objects containing pointers are trickier, however - normally you    // must delete (or delete[]) them if you did new (or new[], respectively)    // them in the constructor.  }  // Any time you need any of (destructor, copy constructor, assignment   // operator), you generally need all three. This is no exception :)  Tile(const Tile& other) : myImage(other.image), row(other.row), column(other.column) {    // This is a copy constructor, called when you initialize a Tile from    // another one. When that happens, we know that the map has the image loaded    // already, but we need to increment the refcount because we added another    // object using that image.    // So we just copy the members (using the initializer list again), and then:    ++images[myImage].second;  }  // It is common to implement assignment operators in terms of the copy  // constructor, whenever there is complicated memory management to do. Here,  // that's not the case, so we don't need to create a temporary like that.  Tile& operator=(const Tile& rhs) {    myImage = other.image;    row = other.row;    column = other.column;    // Since this is an already-existing object, we need to decrement the     // reference count for that old image, and possibly unload it.    dispose();    // Notice that even though dispose() contains all the code invoked in the    // destructor, I factored it out into its own function - again, calling a    // destructor manually is bad mojo. (There is one case in which that should    // be done, but it is a part of some deep magic that beginners should not    // attempt - if curious, you can look it up in the C++ FAQ Lite.)    ++images[myImage].second;  }}