Resource Management question..

Really I just want to know which would be safer... or if one or both has a major pitfall.

Code:

---

namespace Varia
{
    class ResourceMgr
    {
    public:
        ResourceMgr();
        ~ResourceMgr();
       
        void AddResource(const char* p_scriptFile);

        void DeleteResource(int p_index);
    private:
        std::vector<Resource*> Resources;
    };
};

---

or
the same thing but using std::map instead of vector.
I was thinking that if you delete a resource in a vector then every index after the deleted resource would change. Although with the map the index would remain the same with deleting a certain resource. Really I am wondering what would be the downfalls to either approach. I know the classes are not complete, but hopefully I got the point across.

Instead of Resource*, I would hold Resource. If you need a pointer for some reason, use a shared_ptr, or use a pointer container from boost.

As far as map or vector, it sounds like the map might be more appropriate. If you can delete a resource at a specific index and the other resource indexes should not change, then you probably want a map.

If the resources will all be closely populated (few gaps between used indexes) then a vector might be ok and you would just null out the entry when a resource is deleted rather than removing it from the vector.

If you're not sure, I'd use the map because it probably takes less work to implement what you want and would be more clear.

Thank you Daved. The reason for the pointer is because I need Resource to be Dynamically Allocated.
EDIT: shared_ptr is safe to use in STL? Also, is it guaranteed to delete its memory upon deletion of the Manager?

I have another probably simple question.
How do I go through each element of a std::map, and make sure it is freed. (class Destructor)
I am thinking iterators, but I wanted to be sure. So i don't have a million memory leaks.

This is what i think should work, but i am unsure

Code:

---

std::map<int, m_ResourceStruct>::iterator it;
        for ( it = m_resources.begin(); it != m_resources.end(); it++ )
        {
                if ( (*it).second.m_allocated == true )
                {
                        delete (*it).second.m_res;
                        (*it).second.m_res = NULL;
                }
        }

---

The only evidence I can show you against using a map is to trace through the code in the debugger when you access the map elements. There is an awful lot going on just to get to the item in question. I've been leaning strongly towards hash maps for resource management because of what Daved said about vectors (removing items is a big problem) and because of what I've seen in std::map. In order to gain the functionality you need for a resource manager you are going to have to develop your own custom container that makes use of one, more, or no containers in the STL. Whether you use the STL or not again depends on the performance information you gather during your research into other algorithms and container types.

I highly recommend you use pointers in your containers but I also agree with Daved in that if you are going to do that you will want to use boost smart pointers or at the least auto_ptr's. I recommend pointers because it does get rid of a lot of the copying overhead inherent in STL containers. In my own experience I've ran into significant slowdowns when I did not use pointers in the containers. Again this is not a hard-fast rule and you need to research it inside your own code base. A lot of your design decisions will hinge on how your system operates or needs to operate and any guess I make here would be just that...a guess.

For starters I would recommend just getting the resource system working. It does not have to be super fancy it just has to work. Then you can address slowdowns and other possible issues once you have it working. Deciding what approach to take here and now without some hard concrete evidence as to why may lead you out into the weeds. Go code a rudimentary system and play around with it, tax it, break it, get it to crash, etc. Then slowly you can chip away the rough edges and end up with a fairly decent system.

To answer your second question you would delete anything left in the map during cleanup. If you are using pointers to objects on the heap those objects will not be cleaned up by the STL container's destructor. I'm not sure why you are checking if the object was allocated in your destructor. If you allocated memory for the object at any time using the new operator then you must call delete on it regardless of the state of it's internal variables. So the fact that you have an object and can check m_allocated means that you must delete it. In your current destructor code you will leak memory.

Code:

---

for ( it = m_resources.begin(); it != m_resources.end(); it++ )
{
                //If you have a pointer here then you want to call delete on it
                //Whats with the m_allocated check?
        if ( (*it).second.m_allocated == true )
        {
                delete (*it).second.m_res;
                (*it).second.m_res = NULL;
        }
}

---

This appears to me that your resource class has a m_res member that needs cleaned up. Problem is that even though you call delete on that class member you are not calling delete on the object containing the member. So you have effectively leaked the entire map here. The object in the map should cleanup m_res in it's own destructor so that when you call delete on the object, both it's internal object and the object itself are cleaned up.
I'm assuming this code is in the destructor of the manager class.

So if class M has a map of A objects and each A object has a B object you are cleaning up the B object. However you are not cleaning up the A object which means you have leaked the entire map inside of M.

Thank you bubba for that insight. This is the actual code. the m_allocated variable was actually to prevent calling delete on a object that was never allocated in the first place.

Code:

---

/*
        Author: Cody Doughty
        Date:  March 4, 2008
*/
#ifndef RESOURCE_MANAGER_H
#define RESOURCE_MANAGER_H

//For hgeResourceManager
#include <hgeresource.h>

//For STL map class
#include <map>

//For printf
#include <cstdio>


namespace Varia
{
        class ResourceMgr
        {
        public:
                ResourceMgr();
                ~ResourceMgr();
               
                //This will only work if a Resource has not been allocated at the specified index
                void AddResource(int p_index, const char* p_scriptFile);

                //This will return NULL if no resource is allocated at the specified index
                const hgeResourceManager* GetResource(int p_index);

                //Return true if the resource is allocated at the specified index
                bool IsAllocated(int p_index);

                //This will only work if a Resource has been allocated at the specified index
                void RemoveResource(int p_index);

        private:
                typedef struct m_ResourceStruct
                {
                        bool m_allocated;
                        hgeResourceManager* m_res;
                };
                std::map<int, m_ResourceStruct> m_resources;
        };
};
#endif

---

and the implementation

Code:

---

#include "ResourceManager.h"

Varia::ResourceMgr::ResourceMgr()
{
        //nothing to construct
}

Varia::ResourceMgr::~ResourceMgr()
{
        std::map<int, m_ResourceStruct>::iterator it;
        for ( it = m_resources.begin(); it != m_resources.end(); it++ )
        {
                if ( (*it).second.m_allocated == true )
                {
                        delete (*it).second.m_res;
                        (*it).second.m_res = NULL;
                }
        }
}

void Varia::ResourceMgr::AddResource(int p_index, const char* p_scriptFile)
{
        //Check if the index exists
        if ( m_resources.find(p_index) != m_resources.end() )
        {
                //Check if the index is allocated
                if ( m_resources[p_index].m_allocated == true )
                {
                        printf("Resource:&#37;d already allocated.\n", p_index);
                        return;
                }
        }
        //allocate
        m_resources[p_index].m_res = new hgeResourceManager(p_scriptFile);
        m_resources[p_index].m_allocated = true;
        printf("Resource:%d allocated with Script:%s\n",p_index, p_scriptFile);
}

const hgeResourceManager* Varia::ResourceMgr::GetResource(int p_index)
{
        //Check if the index exists
        if ( m_resources.find(p_index) != m_resources.end() )
        {
                //Check if the index is allocated
                if ( m_resources[p_index].m_allocated == true )
                {
                        printf("Resource:%d accessed.\n", p_index);
                        return m_resources[p_index].m_res;
                }
                else
                {
                        printf("Resource:%d not allocated.\n",p_index);
                        return NULL;
                }
        }
        else
        {
                printf("Resource:%d does not exist.\n", p_index);
                return NULL;
        }
}

bool Varia::ResourceMgr::IsAllocated(int p_index)
{
        //Check if the index exists
        if ( m_resources.find(p_index) != m_resources.end() )
        {
                if ( m_resources[p_index].m_allocated == true )
                {
                        printf("Resource:%d is allocated.\n",p_index);
                        return true;
                }
                else
                {
                        printf("Resource:%d exists but not allocated.\n",p_index);
                        return false;
                }
        }
        printf("Resource:%d does not exist.\n",p_index);
        return false;
}


void Varia::ResourceMgr::RemoveResource(int p_index)
{
        //Check if the index exists
        if ( m_resources.find(p_index) != m_resources.end() )
        {
                //Check if the index is allocated
                if ( m_resources[p_index].m_allocated == true )
                {
                        delete m_resources[p_index].m_res;
                        m_resources[p_index].m_res = NULL;
                        m_resources[p_index].m_allocated = false;
                        printf("Resource:%d Freed.\n", p_index);
                        return;
                }
                else
                {
                        printf("Resource:%d exists but not allocated.\n",p_index);
                        return;
                }
        }
        else
        {
                printf("Resource:%d does not exist.\n", p_index);
                return;
        }
}

---

I don't really know if this does what I want it to, but I am hoping it does.

I know it doesn't make much sense to have a ResourceManager for a ResourceManager, but its the only way I could think of to make it work right.

>> shared_ptr is safe to use in STL?
Yes, it is auto_ptr that is not safe. (Note to Bubba, auto_ptr's in STL containers are very bad.)

>> Also, is it guaranteed to delete its memory upon deletion of the Manager?
Yes. when the last shared_ptr pointing to a Resource is destroyed, it will delete the Resource.

>> How do I go through each element of a std::map, and make sure it is freed.
If you used shared_ptr or the ptr_containers from boost, then it would happen automatically and you wouldn't need a destructor. However, your destructor looks fine if you stick to raw pointer.

Based on the whole code, it appears Bubba's worry about leaking the m_ResourceStruct is not a problem, since you hold that by value in the map. My question is why is it necessary? If the m_res pointer is null, then the resource exists but is not allocated, and if it is not null then it is allocated. I think you can store the Resoure* directly in the map and remove the m_ResourceStruct completely.

But what if m_res somehow became a pointer to an existing Resource(external), and it wouldn't be NULL, but the memory would not belong to it still. right?

Quote:

---

I highly recommend you use pointers in your containers but I also agree with Daved in that if you are going to do that you will want to use boost smart pointers or at the least auto_ptr's.

---

From that statement it does appear I was saying use auto_ptr's in STL containers which is not what I intended. I think my brain was going faster than my fingers and I merged two thoughts into one sentence. I was not inferring you should use std::auto_ptr's in containers but might utilize them in general in other places in your code. auto_ptr's have some very ugly copy semantics that make them horrible for use in STL containers. If I misled you on that I do apologize. My original thought was that in places that you are using raw pointers AND that are not in STL containers, using auto_ptr at the very least would be better than raw pointers. Sorry for the confusion.

Quote:

---

Based on the whole code, it appears Bubba's worry about leaking the m_ResourceStruct is not a problem, since you hold that by value in the map.

---

Very true. Yet I'm confused as to why you are storing the resource struct by value but the resource struct itself then has a raw pointer inside of it that points to yet another manager? This is at best confusing.

Raw pointers are of course faster.
As for the vector concern, you could always use pointers but not remove them.
You could just delete the memory and set the pointers to NULL. No removing, no speed hit. And no need to use anything other than vector.
Of course, it's up to you what you want to use.
I always recommend using smart pointers for any pointers, however.
I can't say if boost's smart pointers have the option to explicitly decrement the reference count before the destructor, however. If not, then the program would be a resource hog...

>> But what if m_res somehow became a pointer to an existing Resource(external), and it wouldn't be NULL, but the memory would not belong to it still. right?

Yes, that's fine. If the allocated flag distinguishes between resources allocated locally and those allocated elsewhere then it has a real purpose. Another term might be "owned" since if the resource is owned by the manager than it should be cleaned up by the manager.

If your classes manage memory manually, you'll need to code the copy constructor and copy assignment operator as well (otherwise you'll have two classes deleting the same pointers, or a class full of dangling pointers, should a shallow copy occur).

In this case, however, you'll probably want to make your class non-copiable. For that you'll need a private copy constructor and a private copy assignment operator. These needn't be implemented, as they should never be used.

I thank you all greatly for the insight. I am thinking that a small rewrite of the code may be in order due to the fact that my ResourceManager(s) are very confusing to look at.

Should I make classes that allocate/deallocate all members at construction/destruction, and then have a template class for the resource manager to allocate/deallocate these individual classes?
Sorry if that doesn't make much sense, but my system seems flawed.

Quote:

---

You could just delete the memory and set the pointers to NULL. No removing, no speed hit. And no need to use anything other than vector.

---

There is a problem here. I tried this in my own system and the issue is that you either must use a finite sized vector or use some algorithm to 'scan' the vector and make sure that it is being used optimally. What I found is that the vector grows in size yet you have no way of shrinking it's size. So if you are iterating from 0 to vector::size() and only operating on elements that are non-NULL, your iteration grows each time you add items to the vector and you have no way of removing items from the vector (thus reducing the size).

I solved some of this by remembering the last item that was 'removed' from the vector. In actuality the function just cleaned up the memory of the object in the vector and then set the pointer at the index to NULL. This index was then remembered and the next time a vector 'slot' was requested it would use the stored one. I further optimized it by keeping a stack of 'removed' indices into the vector. If the stack was empty then an item had to be added to the vector via push_back, otherwise the item merely had to be placed according to index stack.

It worked like this:

Add item

• Check the removed index stack.
• If stack is empty, add via push_back
• If stack is not empty, use index from top of stack and add object at this index. Pop index off of stack since it is now being used.

Remove item

• Clean up memory of object at index being removed
• Set value of vector[index] to NULL
• Push index that is being removed onto index stack

This really optimized the use of the vector and then I realized that I might as well use an array for this type of system. So I dumped the vector and changed to array. The only change to the algorithm was that when adding an object if the index stack was empty the number of elements in the array had to be incremented. So if you allocated 3000 'slots' you may only be using 5 of them at one time. Since you are using the index stack to optimize re-use of empty slots the array never became fragmented. The ONLY drawback I found is that the number of actual elements in the array could only grow and never shrink. A possible fix is to keep a lower bound variable that would track the minimum index in the array. Then you would also need a Begin() and End() function that would return the actual beginning of the array and the actual end. So iterating from Begin() to End() does not mean you are iterating from 0 to the max number of elements in the array.

Example:

1. Array is empty. Array memory size is 4000 elements.
2. Add item
3. Array begin is 0
4. Array end is 1 (end always returns 1 past the current max index in the array)
5. Number of elements in array (array size()) is 1.
6. Add 10 items
7. Begin = 0, End = 10, Size = 11
8. Remove items at index 1, 5, 7, 9 (adds 1,5,7,9 to stack)
9. Add item - since stack is not empty use stack info for index of new item - 9 would be the index
10. Add item - stack not empty, 7 is now the index

I hope this illustrates clearly how the system works. In my Asteroids game I could use well over a total of 1000 asteroids in the level and yet only use 300 or so actual array indices. It all depends on how often objects die and how often they are created.

I like the idea you provided Bubba. I will try writing it, and see if I can get it working. Also, is it reasonable(Safe) to use a template class for the Manager?

Quote:

---

Also, is it reasonable(Safe) to use a template class for the Manager?

---

Safe = yes. Reasonable = depends on your design.
If you need the complexity and robustness it offers then sure but if it just serves to obfuscate the code or derail you from the final goal then I'd say no. Besides if you design it correctly in the first place you can always add template support later on in the project.

I actually have a templated version of what I described. Let me know how yours turns out and we can compare code. I've called it a SmartArray although it's not very smart if it cannot reduce the max index. Perhaps you can solve this problem.

I am going to work on it, and see. I am sure your code will be far better than mine. This thought is based strictly on observation.

I see Bubba has put a lot of effort and thought into this...

Quote:

---

I see Bubba has put a lot of effort and thought into this...

---

Yes I had to for my recent game. Since my system operated on ID's (indexes into containers) it really sucked when I removed one asteroid and then every asteroid that had an ID greater than the one I just removed disappeared. Then I knew I had to create a custom container. There is no simple solution or STL container you can use as-is to gain the functionality you need. You could use a map for this but performance would become an issue.

Raigne if you would like the source code for the project I'd be more than happy to give it to you. It would clearly illustrate how the array setup works. There are also functions that will output debug info to the screen about how many indices are actually being used in the array and the size of the current index stack.

So what else are you using? Blazingly fast dynamic arrays?
I'm pretty sure the container could be made "smarter" to "downsize" the array too, but I'm guessing it's just not worth the time it would take to get such a system working, huh?

That would be wonderful Bubba. Do I just PM you my email? Thank you so much.

Quote:

---

I'm pretty sure the container could be made "smarter" to "downsize" the array too, but I'm guessing it's just not worth the time it would take to get such a system working, huh?

---

It's worth the time because I will use it in my StarX project which is my main focus right now. I just haven't got around to it mainly due to work and my insistence on waiting till the weekend to do hobby coding. GTA Vice City and the COD's have had my attention for some time now. :D
I've never beaten Vice City so I want to beat it.

Quote:

---

That would be wonderful Bubba. Do I just PM you my email? Thank you so much.

---

Sure. I just loaded the game up to see if it still works and it does. I'll zip the project up minus the ncb and pdb's since they are so huge.

I sent you the address.
Also, I was wondering are there any third party libraries that the project uses that i may not have?

You will need the DirectX Aug. 2007 SDK as well as DirectX 9.0c installed on the system.

I'm trying to clean up the folder structure a bit so I'll email it when I get it building with the new structure. Also I have not tested release mode yet nor configured it so it probably won't do a release build.

You will need to change the library paths and include paths for the DirectX headers and libs to where you install the DirectX SDK. The dependencies should be set but if not I'll let you know which libs it needs to link with.

Ok, Thank you very much for all the assistance.

Code has been sent. Let me know if you have any problems.

As a test I increased the starting asteroid counts, spawn asteroid counts, fire rate of the ship, and speeds of everything.

This is a ridiculous situation that is obviously far too hard to be any fun but the engine and underlying container handle it quite well.

This uses the container I've described above.

It looks good Bubba. I got it working for the most part I think. I get a lot of exceptions, but I am working them out. I looked and your smartArray class, and I am seeing if I can where I can change the size of it.

[EDIT]: I got it working, but I am still getting a few errors in the debugger so, if I can get it working completely I will make a thread about it.

What specific errors are you getting?

I am pretty sure the remaining errors are due to bad variable data. I think when I remove an index from the array that it is doing the wrong thing to the m_Size variable.

may have something to do with this piece..

Code:

---

...
--m_Size;
delete m_Array[m_Size+1];
...
m_Size += 50;
m_Array = copyArray(new Array[m_Size]);
...

---

the delete works, and the copy works, but after the copy phase I can only access the elements I copied, I get memory errors when I try to use the indexes after end of the previous array size. If that makes sense.

**deleted**
EDIT: there was a bad error with memory allocation... New one is below

I don't understand why you have a struct inside the class.

Code:

---

template <class T>
class SmartArray
{
  public:
    ...
  private:
    T* m_pArray;
    unsigned int m_start;
    unsigned int m_end;
    unsigned int m_num_elems;
    unsigned int m_max_elems;
    std::stack<unsigned int> m_IndexCache;
};

---

To me this is much clearer instead of having both a type for the SmartArray and a type inside the SmartArray class. I'm lost as to why you have a typedef in the class.

I don't know what i was thinking with the struct, unless i was planning on having ownership of the type, but as for the raw array I didn't think it would work well since it is hard to modify the size of an array that contains data.

Modified the post with the template manager, and changed it to not use the struct.

This one seems pretty stable... Maybe not, but looks like it

Code:

---

/*
        Author: Cody Doughty
        Data:  March, 6, 2008
*/
#ifndef SMART_ARRAY_H
#define SMART_ARRAY_H

#include <cstdio>

#include <vector>
#include <list>

namespace Varia
{
        template<class Type>
        class XArray
        {
        public:
                XArray(unsigned int p_iMax = 2000, bool p_bDebug = false):m_iMax(p_iMax),m_bDebug(p_bDebug),m_iSize(0)
                {
                        if (m_bDebug)
                        {
                                printf("Creating XArray. Size = &#37;d.\n", m_iMax);
                                printf("-->Estimated memory usage: %dbytes.\n", (sizeof(Type)*m_iMax));
                        }
                        m_vArray.resize(m_iMax);
                        std::vector<Type*>::iterator it;
                        for ( it = m_vArray.begin(); it != m_vArray.end(); ++it )
                                (*it) = NULL;
                }

                ~XArray()
                {
                        std::vector<Type*>::iterator it;
                        for ( it = m_vArray.begin(); it != m_vArray.end(); ++it )
                                if ( (*it) != NULL )
                                {
                                        delete (*it);
                                }
                }

                void  SetDebug(bool p_bDebug)
                {
                        m_bDebug = p_bDebug;
                }

                int  AddElement(Type* type)
                {
                        if ( m_iSize >= m_iMax && m_vList.empty() )
                        {
                                return -1;
                        }
                       
                        if ( !m_vList.empty() )
                        {
                                unsigned int index = m_vList.front();

                                if ( m_vArray.at(index) == NULL )
                                {
                                        if ( m_bDebug )
                                                printf("Setting Resource:%d\n",index);
                                        m_vArray.at(index) = type;
                                        m_vList.erase(m_vList.begin());
                                }
                                return index;
                        }
                        else
                        {
                                if ( m_bDebug )
                                        printf("Setting Resource:%d\n",m_iSize);
                                m_vArray.at(m_iSize) = type;
                                ++m_iSize;
                                return m_iSize-1;
                        }
                }

                int          RemoveElement(unsigned int p_iIndex)
                {
                        if ( p_iIndex <= m_iMax-1 )
                        {
                                if ( m_vArray.at(p_iIndex) != NULL )
                                {
                                        if (m_bDebug)
                                                printf("Removing element:%d\n",p_iIndex);
                                        delete m_vArray.at(p_iIndex);
                                        m_vArray.at(p_iIndex) = NULL;
                                        m_vList.push_back(p_iIndex);
                                        return p_iIndex;
                                }
                                else
                                {
                                        return -1;
                                }
                        }
                        return -1;
                }

                void  IncrementSize()
                {
                        if ( m_iMax < m_vArray.max_size() )
                        {
                                if ( m_bDebug )
                                        printf("Incrementing Array size from %d to %d.\n",m_iMax,m_iMax+1);
                                ++m_iMax;
                                m_vArray.push_back(NULL);
                                m_vList.push_back(m_vArray.size()-1);
                        }
                }

                void DecrementSize()
                {
                        if (!m_vArray.empty())
                        {
                                if ( m_bDebug )
                                        printf("Decrementing Array size from %d to %d.\n",m_iMax,m_iMax-1);
                                if ( m_vArray.back() != NULL )
                                        delete (m_vArray.back());
                                if ( m_iMax == m_iSize )
                                        --m_iSize;
                                --m_iMax;
                                m_vArray.pop_back();
                        }
                }

                void  Clear()
                {
                        if ( m_bDebug )
                                printf("Clearing Array.\n");
                        std::vector<Type*>::iterator it;
                        for ( it = m_vArray.begin(); it != m_vArray.end(); ++it )
                                if ( (*it) != NULL )
                                {
                                        delete (*it);
                                }
                        m_vArray.clear();
                        m_iMax = 0;
                        m_iSize = 0;
                }

                Type* GetElement(int p_iIndex)
                {
                        if ( p_iIndex < m_iMax )
                                return m_vArray.at(p_iIndex);
                }
               
        private:
                bool m_bDebug;
                //
                unsigned int m_iMax;
                unsigned int m_iSize;

                std::vector<Type*> m_vArray;
                std::list<int>          m_vList;
        };
}

#endif //SMART_ARRAY_H

---

Just a few observations:

You need to construct members in the same order they are declared. (Some compilers hate it when you don't.)

You need to construct the 'std::vector' as well. (You can specify the size in the constructor.)

There is nothing wrong with deleting a null pointer.

You need a copy constructor and assignment operator, or you need to disallow them.

Anyway, I don't know what your strategy is, but you might want to look at implementing a 'span block'* instead of just recording every removal.

Say you want to remove element '14': First check if any span starts or ends at element '13' or '15'. If a span ends at element '13' you simply increment the span length by 1 and erase the element. If a span starts at element '15' you decrement the span starting position by 1, increase the span length by 1 and erase the element. If neither of these are available you start a new span block with the position 14 and length of 1 and erase the element.

Now again, I don't know your strategy. However, if you may be adding or erasing ranges (say elements '13', '14', [...] '37', '38') often this will be a nice improvement. If your strategy involves... a wide range of ranges (adding ranges of only a few elements and ranges of many elements) you may want to provide a way to sort the list of span blocks by length. The kicker here is two additional functions: 'AddRange(Type * StartPosition, size_t ElementCount)' and 'RemoveRange(int StartPosition, size_t ElementCount)'. Without these functions the span block would be too costly for average use.

My strategy (for the curious):
I was actually using something very similar to this in an old tile engine of mine. Many tiles were loaded at startup. Most tiles were around only for a specific field. Dealing with towns, where a particular building may have it's own set of 9 to 512 tiles, was the rationale for the span block implementation. It was slow restoring and removing even the small building sets every time the character entered/exited a building. I changed things so that tile sets were cached. The cache was reclaimed by key events.

Soma

* Not actually what it is called, but I think the more descriptive name useful. It is actually an idea heavily associated with "first fit" and "best fit" allocators.

I talked with a co-worker over lunch today and he had a very good idea on how to solve the issue of increasing indices in this algorithm.

Raigne, PM me and I'll show you a possible solution. Given this would correct a serious flaw in an otherwise very fast and good container this fix may prove extremely viable. If it does indeed solve the problem I will most likely use this container for my entire resource management system.

Why not post it publically so anyone can see? Or is the code restricted?

No this is for a personal project. I'll post it as soon as I verify it works. I'm basically treating each element in the array as a node in a linked list.