Halsafar's Cpp SLAQ Library

SLAQ - Stack, List, Array, Queue
Sound it out -- C++ Slaq - Slack -- Easy :)

Unfortunatly the list and queue have not been included, but the abstract SLAQ class has been included with two derives, Stack and Array. The List is a managed list which uses a stack of free_id's to allow very quick insertion, in fact up to the 50,000 index mark it is incredibly fast it is due to this fact I have not included it.

The app_Main.cpp includes a small benchmark which runs a console app, asks the allocation size and does a comparison: Hals Array VS std::vector. It compares the alike push_backs functions and plain assigments.

On my computer the assigment match ties at exactly 20 indices. Anything less than 20 and vector seems to win, anything above 20 and my array seems to make very large jumps. The push_back match acts much the same except they seem to stay pretty close even though mine does jump ahead.

Unfortunetly, a RELEASE mode compile completly changes everything -- the assigment match will almost ALWAYS be won by Hals Dynamic Array, where on the other hand the push_back() match will always been won by vector.

A last note, this is not even close to version 1.0 of this release and it is really meant for games. In fact the managed list, in release mode, can process 50,000 push's faster than anything I've seen, but it is a list method where you do not need to know the precise location of your members (a unit pool for example). The library will eventually be out for full release and I hope to get that release mode push_back to fight harder. Most of this stuff is pretty basic, but it does show a use of complex memory managment combining both some C and C++ functions.


Thanks for downloading, please leave you comments.
If you wish to incorporate any of this code then just allow me the honor of knowing where it is being used and by who otherwise I have no objections.
Halsafar

memset is slow compared to memcpy
This was in your ReAlloc function:

if (uiSize > m_dwMaxIndex) { //If we are enlarging the array then we must set to 0
memset(m_Begin+m_dwMaxIndex, 0, m_SizeOf * (uiSize-m_dwMaxIndex));

I can't see it as being really necessary, I think you should remove it.

Not necessary but it initializes all indices to 0.
If memcpy does it faster then beautiful.

I noticed a big difference from your to mine was the fact I used malloc and realloc. You use new and had to temp the array, create a new array, copy the old, delete the old. This is all elimated with realloc.

Yes, I looked into realloc and figured that out but that was not the major performance hit. It was Resizing only by 10 each time instead of by .2f.

I probably need to stick with new delete because I probably will have destructors and constructors that need called.

What do you mean constructors/destructors which require new??
I have found that malloc and new --- free and delete are pretty well the exact same and can be used in any situation. It is usually a point of preference -- also if you need to resize a lot without data loss then malloc/realloc is your BEST choice.
Just never mix a malloc allocation with delete :)

Do you want comments on the code? Be warned, they would be harsh.

(Correction: after looking at the code a little bit, I must say that they would be very harsh.)

CLICK
I'll give it a try though because I really did want to use realloc.

Whats wrong with the code?
I expect some critism, how else do I find my flaws.
Programming has habits, often bad ones as habits tend to be.