Thread: std::map question.

I have the following class that basically just holds a texture handle, and manages the memory of the texture.

Code:

#ifndef XTEXTURE_H
#define XTEXTURE_H

#include <hge.h>

namespace Varia
{
    class Texture
    {
    public:
        Texture():mTexture(0)
        {
            mHge = hgeCreate(HGE_VERSION);
        };
        ~Texture()
        {
            if ( mTexture != 0 )
                mHge->Texture_Free(mTexture);
            //Release the HGE pointer
            mHge->Release();
        };

        //This will not allow you to overwrite the existing texture
        HTEXTURE CreateTexture(const char* filename, bool mipmap)
        {
            if ( mHge != NULL )
            {
                if (mTexture!=NULL)
                    return (mTexture);

                mTexture = mHge->Texture_Load(filename,0,mipmap);
                return (mTexture);
            }
            return 0;
        };

        HTEXTURE  DeleteTexture()
        {
            if ( mHge != NULL )
            {
                mHge->Texture_Free(mTexture);
                (mTexture=0);
            }
        };

        HTEXTURE GetTexture()
        {
            return (mTexture);
        };

    private:
        HGE* mHge;
        HTEXTURE mTexture;
    };
};

#endif//XTEXTURE_H

I also have two other classes that are capable of holding data. One is a template class for internal stuff (user can't modify), and one that contains std::maps that I hope will allow me to implement my script system more easily.
Really it is just a question of speed in indirection. Also if indirection is worth all the extra code required.
basicly I have either

Code:

std::map<size_t, Varia::Texture> mTextures;
//Or
std::map<size_t, Varia::Texture*> mTextures;

I want to use std::map, but I hear that it is substantially slower than std::vector(although with map you don't have to manage the indexes).

Thank you greatly for any assistance.

Originally Posted by Raigne

I want to use std::map, but I hear that it is substantially slower than std::vector(although with map you don't have to manage the indexes).

If you think a linear search through a vector is going to be more efficient than a logarithmic search in a map, then you have quite a bit of studying to do...

Instead of hypothesizing some imaginary performance problems, just write it the way that makes the most sense and see if it's fast enough. If not, you might consider specific optimizations. The difference in performance between holding objects and holding pointers to objects is going to be dwarfed by the time needed to traverse the map or vector, in any case.

Originally Posted by Raigne

Thank you brewbuck, but still I am going to make the assumption that at any given time, the size of these map and/or vectors will not exceed 100, so the searching I don't think will matter anyhow. I am more looking for access time.

I still think you are imagining the problem. Try it with the map, and if things are slow, profile it. The containers are not usually the problem.

What does the key to the maps represent? Are they numbers that start from 0 and always increment by 1? Do they jump around randomly? Will you be filling your map once, then accessing it many times without inserting or deleting?

I agree with brewbuck, this is probably not going to be a problem. However, if the key is just a number starting 0 or 1 that goes up sequentially, then a vector probably makes sense. If the numbers are sparsely populated within a range, then maybe not.

Another common solution for sparsely populated numbers if you insert them all once in the beginning is to add them to the vector then sort, and when you want to access an element use binary_search. However, that will still be logarithmic lookup time, and will only potentially optimize the constant factors.

>> I would recommend against using std::map, at least under MS STL.

I use std::map from the MS standard library all the time and it works great.

There were issues with older versions of the library (like the one for VC++ 6.0 and the one called SXL), but those are so old you probably shouldn't be using them anyway.

There's no reason to switch to a custom container unless you are working in an area that has very specific functional and performance requirements that aren't met by the standard containers. In the case of a key/value pairing, a map is the logical choice, and only in some instances (like those I mentioned) does it make sense to use something else.

BTW, Bubba, have you looked at using std::tr1::array in your custom container? It is like vector but is a fixed size array specified at compile time and so it has performance advantages of statically sized arrays over dynamic ones.