Hey, I have a few very related questions, as you''ll see why in a minute. The first is simply this : In browsing what in my opinion is one of the more readable guides to the STL on the net, (http://nexus6.cs.ucla.edu/software/documentations/STL/) they say that the STL supports a hash_map template. Unfortunately, it seems as it VC++ 6.0 doesn''t have one. Is there any work around? Or do I have to go ahead and write up my own hash table? As for WHY I need a constant-time map template, here''s my situation. I''m currently in the process of allowing my 2d overhead game to take advantage of 3d hardware, specifically the Glide API. In my current code, each Bitmap owns its own data in system memory (I''ve so far only done software drawing, so no DX surfaces). However, now I have to manage a contested, limited resource (texture memory) for all of my bitmaps. After some thought, it seems like the most elegant method of doing this is by using a map. Due to the nature of the resource (read as: limited) my render class owns the Texture memory; before drawing a sprite retrieves from the hashmap the information on where in texture memory its image is. This allows for the render class to dynamically add and remove textures as needed; When the bitmap calls for a texture retrieval, if it isn''t in the map my render class will then go hunt for a place to upload the texture to. The map key is simply the sprite''s own data pointer. Since in my implementation, even if you have many sprite objects you only have 1 data pointer shared for all sprites using that bitmap, this is an easy way to manage the bitmaps in the texture memory. Like I said, this is what I''ve come up with after some thought, but I''m sure there are some other ways out there. I thought about having each sprite simply own its own chunk in texture memory, but that introduces all sorts of problems about what happens when the free space runs out. Lastly, I thought about emulating a hash table by way of just using an STL vector of TextureInfo, with the key in this case simply the index into the vector. This requires that I give each bitmap resource a number that corresponds to its data in the index. This is doable as well I suppose; I could have a static int in my sprite class that simply increments and assigns to each loaded bitmap. But it seems more messy, and has more potential to screw up. And lastly, why not just use a regular STL map? Since the texture retrieval is going to be done on EVERY sprite blit EVERY frame, it needs to be 1) constant time, and 2) fast. The only two data structures that would fit the bill that I know of is a vector used like I described above, or a hashmap. But I suppose this has to be a pretty common problem, right? What do the rest of you do to manage your texture memory? Am I on the right or wrong track in having my render class own the texture mem? I know when dealing with DDraw its pretty easy; when you run out of video memory, you just bump your surfaces into system mem. Implementing a system for that is pretty trivial. But when dealing with 3dhardware, you can''t do that... - Remnant
- (Steve Schmitt)

The hash_map template classes are an addition to the "sgi" STL. They are also available, I think, in the stlport distribution, which should work with MSVC.

The STL that comes with MSVC is a contracted port of Dinkumware''s STL (www.dinkum.com), and they have some patches available for the version included with MSVC. They also have a "full" version available for sale (the one that they were contracted by MS to build isn''t complete, because it was based on the draft standard, which has now been approved).

The stlport distribution is HP STL, modified by SGI (to add hash maps, etc.) and then modified by Boris Formitchev (et. al.), to be as portable as possible.

Check out http://www.stlport.org/ for more info.