#### Archived

This topic is now archived and is closed to further replies.

# STL map set

This topic is 5911 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Anyone know where I can get an STL map and STL set implementation that uses 16 bit indices instead of 32 pointers. Basically I have an editing tool that writes a map into a contiguaous block of memory and then writes the block to a file. So now (in a game engine) I want to read the block from the file, and point to the block and type cast it as a map.

##### Share on other sites
What do you mean by "type cast it as a map"? Is the entire map class, including internal variables, stored in the data chunk written to the file, or is only the data inside the container stored? Either way, how could you possibly assume that the implementation of the map class you find would match the map class used by the editing tool exactly?

I would read in the individual elements and add them into the map as you read them in, rather than trying to read the whole chunk into memory and do who-knows-what with it.

- null_pointer

##### Share on other sites
Repeat after me 100 times : "I will never save pointers, nor anything with a non-controlled internal representation."

Your only solution is to spit out the keys and elements one by one instead of as a ''map''.

##### Share on other sites
quote:

Is the entire map class, including internal variables, stored in the data chunk written to the file

Yes. I'm working on a PS2 game where we load big chunks of memory off the DVD at a time. Its very efficient that way, and decreases our loading time. Of course, to do this, we have to write our own container classes, where we can serialize the entier container and its elements to a file (similar to the way MFC CObject and MFC containers work).

Our editing tools already do alot of work to align our data in the file(s), and we have to use a TOC (Table Of Contents) file, that stores the file headers, alignment, offsets, etc separate from the actual data.

For example, Textures on PS2 have 128 bit tags which must be 16-byte alighed for faster DMA transfer to GS memory. So all our textures are lined up in a file, each texture's file header gets written to a Texture TOC file. The Texture file is burned onto the DVD, and then Sony has a library function to get the exact Disk-Sector from the file, so given the base disk-sector, and the offsets from our TOC, we can compute the exact disk sector of any Texture. Knowing the exact disk sector ahead of time makes for faster disk seeking and streaming. All this work just to reduce loading time.

Of course, the TOC uses a binary tree on the PS2. Note that I can assume the data I'm working with is read-only. Right now I load my TOC and build an AVL tree out of it. Once the AVL tree is built, it is read-only. There is no significant performance difference between binary-searching an array, and searching a binary tree. So I should be able to build my tree with the editing tool, and just load the TOC block, typecast it and search.

Building the AVL tree for a file TOC is not performance critical, but 32 bit pointers do consume more memory than I like to consume. Also, a (read-only) tree with 16 bit indices instead of 32 bit pointers is useful for many other (read-only) things. For exapmle Binary Spatial Partitioning. The more geometry in a scene the bigger a BSP gets.

Anyway, I'm tired of re-writing the same container code over and over again and I've been copying pasting and modifying STL code, so I can use 16 bit indices instead of 32 bit pointers. I'm just wondering if anyone has it done already.

Edited by - Marsupial Rodentia on December 17, 2001 8:38:45 PM

##### Share on other sites
It''s doubtful one exists, as STL containers have to be able to return objects by value, and therefore using indices internally would mean that it has to include whatever those indices refer to. Besides which, you can''t dictate how the internals of a map are stored (they almost certainly wouldn''t be using a contiguous chunk of memory such as you are) so a type cast would go horribly wrong. Sorry.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

##### Share on other sites
  #define int short #include #undef int

?

erm, that probably won't work. The iterators have to be the same size as pointers on the machine (seeings how they're pointers...).

And you have to ensure that it loads into the exact same place in RAM eveytime, which I suppose is possible on the PS2...

Magmai Kai Holmlor

"Oh, like you've never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

Edited by - Magmai Kai Holmlor on December 18, 2001 1:43:54 AM