Dynamic array(request)

I think a dynamic array would be a useful plugin.One that could change it's size as data was put in and taken out at runtime.

I keep clicking these thinking someone's actually made one... could we make a rule to add [request] or [plugin] depending on what's been/being made? (or [effect] or [behavior] or whatever)

Your right would make things clearer.Edited post.

I will see what I can do westray

I'm an amateur at C++, so dynamic arrays are still fairly new to me. But I will need to know them well to complete my current personal project

please remind me when you see me in chat, or send me a pm in a week if you still haven't seen another reply here.

this should be very easy to make

The array object resizes itself bigger if you set an element outside the array bounds, so it's a kind of dynamic array.

Array is not really flexible when it comes to dynamically adding and removing elements (which hashtable does well, but is somewhat limited; ordering etc.).

Stack and queue, please! (FIFO, LIFO, etc.)

in light of what ashley said about it changing size, does it still seem necessary?

and if so, in addition to stack and queue, and mirrors of the original array plugin actions and conditions, what features would you like to see?

edit::oh wait!!!

I know one I always wanted for construct, and that was to be able to create an array of objects that you can pick by array index, I know most people think this is the same as UIDs, but it's not, really. that method is very annoying to implement, and requires you to work around all the features that normally make construct so great!.

also, mipey

in stack and queue, can you give me a specific example of what you would be using this for, so I can setup the conditions, and actions to work well in the situation. I haven't had a need for stacks as of yet.

edit::oh wait!!!

I know one I always wanted for construct, and that was to be able to create an array of objects that you can pick by array index, I know most people think this is the same as UIDs, but it's not, really. that method is very annoying to implement, and requires you to work around all the features that normally make construct so great!.

Actually you might need something like this for your bitmapfont object.

stack (LIFO - Last In, First Out) - data is layered on top of each other, the oldest at bottom, newest at top, useful where you need layered stuff such as tiers of units, defenses, whatever in games. Moreover, GUI windows often are stacked on top of each other; you have to close topmost to get below, so you don't accidentally alter something below the active window. The stack object would help ensure this. Also it could be used as game resource storage or an active game element (train wagon coupling, where you have to uncouple outer wagons to get the inner one).

queue (FIFO - First In, First Out) - data is queued, the oldest element is the first one to go out, which is very useful for tack/order queuing, turn management (turn based games!!), AI routines and so on. You would add new elements and know that eventually they will be processed. This would make turn based games and AI development MUCH easier.

As for array changing size, does it change size when an element is removed? I think that you have to manually remove the element. Moreover, whenever you take an element, you have to move ALL other elements to their new positions etc.; stack and queue would take care of that automatically.

What about linked lists? Does construct include these?

Linked lists are very efficient data structures for handling large amounts of objects, as each element in the list knows the previous and next objects in the list. If an object is removed you simple update the links for the previous and next objects, not the entire list.

Lots of info about data structures here:

http://lab.polygonal.de/ds/

More data containers are needed, but I'm not convinced that many if any uses yet would require such optimized containers. Could be wrong though.

actually I've read in many places that you shouldn't use lists and other dynamic structures for stuff that changes a lot.

Turns out allocating memory is rather slow, so it's better to have an array/pool of resources and activate/desactivate when needed. Creating a new one is activating a deactivated resource and overwriting its values.

You can do that with arrays already. I could post an example if needed.

The overhead of the event engine is high, so the algorithmic benefits of various containers would probably be much less noticable.